JiBX

Binding compiler throws IllegalStateException with IBM JDK 6 and Linux amd64

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: JiBX 1.1.6
  • Fix Version/s: JiBX 1.2
  • Component/s: core
  • Labels:
    None
  • Environment:
    Ubuntu 64-bit. Ant 1.7.0. IBM JDK 1.6.0 build pxa6460sr1-20080416_01(SR1). JiBX 1.1.6a
  • Number of attachments :
    0

Description

Binding using ant script works fine with Sun JDK 6 and IBM JDK 5. Fails with IBM JDK 6. I've tried on 2 projects and get same results on each.

Relevant parts of Ant script:

<target name="init">
<path id="build.classpath">
<pathelement location="$

{lib}/jibx-run.jar" />
<pathelement location="${lib}

/xmlunit.jar" />
</path>

<path id="bind.classpath">
<path refid="build.classpath" />
<pathelement location="$

{lib}/jibx-bind.jar" />
<pathelement location="${lib}

/bcel.jar" />
<pathelement location="$

{lib}

/jibx-extras.jar" />
</path>

<!-- JiBX binding compiler task definition -->
<taskdef name="bind" classname="org.jibx.binding.ant.CompileTask">
<classpath refid="bind.classpath" />
</taskdef>
</target>

<!-- Compile the bindings -->
<target name="bind" depends="init" description="Run the JiBX binding compiler">
<bind verbose="true">
<classpath>
<path refid="build.classpath" />
<path path="$

{dest.dir}

" />
</classpath>
<bindingfileset dir="$

{src.dir}

">
<include name="*.xml" />
</bindingfileset>
</bind>
</target>

Console output with IBM JDK 6:

nigel@lapcat:/local/work/Seascape/jibx_extras_test$ export JAVA_HOME=/opt/ibm/java-x86_64-60/
nigel@lapcat:/local/work/Seascape/jibx_extras_test$ java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pxa6460sr1-20080416_01(SR1))
IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460-20080415_18762 (JIT enabled, AOT enabled)
J9VM - 20080415_018762_LHdSMr
JIT - r9_20080415_1520
GC - 20080415_AA)
JCL - 20080412_01
nigel@lapcat:/local/work/Seascape/jibx_extras_test$ ant bind
Buildfile: build.xml

init:

bind:
[bind] Using the following paths:
[bind] /local/work/Seascape/jibx_extras_test/lib/jibx-run.jar
[bind] /local/work/Seascape/jibx_extras_test/lib/xmlunit.jar
[bind] /local/work/Seascape/jibx_extras_test/output/classes
[bind] Using the following binding paths:
[bind] /local/work/Seascape/jibx_extras_test/src/bindingdom1.xml
[bind] Running binding compiler version jibx_1_1_6a
[bind] Error running binding compiler
[bind] java.lang.IllegalStateException: The current state is not START_DOCUMENT.
[bind] at com.ibm.xml.xlxp.api.stax.msg.StAXMessageProvider.throwIllegalStateException(StAXMessageProvider.java:46)
[bind] at com.ibm.xml.xlxp.api.stax.XMLStreamReaderImpl.getEncoding(XMLStreamReaderImpl.java:1357)
[bind] at com.ibm.xml.xlxp.api.stax.XMLInputFactoryImpl$XMLStreamReaderProxy.getEncoding(XMLInputFactoryImpl.java:304)
[bind] at org.jibx.runtime.impl.StAXReaderWrapper.startTag(StAXReaderWrapper.java:110)
[bind] at org.jibx.runtime.impl.StAXReaderWrapper.next(StAXReaderWrapper.java:239)
[bind] at org.jibx.runtime.impl.UnmarshallingContext.toStart(UnmarshallingContext.java:515)
[bind] at org.jibx.runtime.impl.UnmarshallingContext.unmarshalElement(UnmarshallingContext.java:2766)
[bind] at org.jibx.binding.model.BindingElement.readBinding(BindingElement.java:760)
[bind] at org.jibx.binding.model.BindingElement.readBinding(BindingElement.java:776)
[bind] at org.jibx.binding.model.BindingElement.validateBinding(BindingElement.java:794)
[bind] at org.jibx.binding.Utility.validateBinding(Utility.java:223)
[bind] at org.jibx.binding.Utility.loadBinding(Utility.java:264)
[bind] at org.jibx.binding.Utility.loadFileBinding(Utility.java:408)
[bind] at org.jibx.binding.Compile.compile(Compile.java:296)
[bind] at org.jibx.binding.ant.CompileTask.execute(CompileTask.java:248)
[bind] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[bind] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[bind] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:59)
[bind] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:39)
[bind] at java.lang.reflect.Method.invoke(Method.java:612)
[bind] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
[bind] at org.apache.tools.ant.Task.perform(Task.java:348)
[bind] at org.apache.tools.ant.Target.execute(Target.java:357)
[bind] at org.apache.tools.ant.Target.performTasks(Target.java:385)
[bind] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
[bind] at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
[bind] at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
[bind] at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
[bind] at org.apache.tools.ant.Main.runBuild(Main.java:698)
[bind] at org.apache.tools.ant.Main.startAnt(Main.java:199)
[bind] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
[bind] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
[bind]

BUILD FAILED
/local/work/Seascape/jibx_extras_test/build.xml:43: JiBXException in JiBX binding compilation

Total time: 0 seconds

Console output with IBM JDK 5:

nigel@lapcat:/local/work/Seascape/jibx_extras_test$ export JAVA_HOME=/opt/ibm/java2-x86_64-50/
nigel@lapcat:/local/work/Seascape/jibx_extras_test$ ant bind
Buildfile: build.xml

init:

bind:
[bind] Using the following paths:
[bind] /local/work/Seascape/jibx_extras_test/lib/jibx-run.jar
[bind] /local/work/Seascape/jibx_extras_test/lib/xmlunit.jar
[bind] /local/work/Seascape/jibx_extras_test/output/classes
[bind] Using the following binding paths:
[bind] /local/work/Seascape/jibx_extras_test/src/bindingdom1.xml
[bind] Running binding compiler version jibx_1_1_6a
[bind] binding bindingdom1:
[bind] context (mp#=1) (cv#=0) (fm#=0)
[bind] mapping class extras.DomContact1 to element contact (#0)
[bind] context (cv#=0) (fm#=0)
[bind] element wrapper contact
[bind] object binding for extras.DomContact1 create class extras.DomContact1
[bind] structure ordered
[bind] element first-name from property m_firstName (java.lang.String)
[bind] element last-name from property m_lastName (java.lang.String)
[bind] element phone from property m_phone (java.lang.String)
[bind] direct property using optional property m_information (org.w3c.dom.Element)
[bind] direct marshaller/unmarshaller reference
[bind] Generating code for mapping extras.DomContact1
[bind]
[bind] Wrote 2 files
[bind]
[bind] extras.JiBX_bindingdom1DomContact1_access2 output file size is 1839 bytes
[bind]
[bind] extras.JiBX_bindingdom1Factory output file size is 2627 bytes
[bind]
[bind] Kept 2 files unchanged:
[bind] extras.DomContact1
[bind] extras.JiBX_bindingdom1DomContact1_access1
[bind]
[bind] Deleted 2 files:
[bind] extras.JiBX_bindingdom1Factory
[bind] extras.JiBX_bindingdom1DomContact1_access

BUILD SUCCESSFUL
Total time: 0 seconds

Console output with Sun JDK 6:

nigel@lapcat:/local/work/Seascape/jibx_extras_test$ export JAVA_HOME=/usr/lib/jvm/java-6-sun
nigel@lapcat:/local/work/Seascape/jibx_extras_test$ ant bind
Buildfile: build.xml

init:

bind:
[bind] Using the following paths:
[bind] /local/work/Seascape/jibx_extras_test/lib/jibx-run.jar
[bind] /local/work/Seascape/jibx_extras_test/lib/xmlunit.jar
[bind] /local/work/Seascape/jibx_extras_test/output/classes
[bind] Using the following binding paths:
[bind] /local/work/Seascape/jibx_extras_test/src/bindingdom1.xml
[bind] Running binding compiler version jibx_1_1_6a
[bind] binding bindingdom1:
[bind] context (mp#=1) (cv#=0) (fm#=0)
[bind] mapping class extras.DomContact1 to element contact (#0)
[bind] context (cv#=0) (fm#=0)
[bind] element wrapper contact
[bind] object binding for extras.DomContact1 create class extras.DomContact1
[bind] structure ordered
[bind] element first-name from property m_firstName (java.lang.String)
[bind] element last-name from property m_lastName (java.lang.String)
[bind] element phone from property m_phone (java.lang.String)
[bind] direct property using optional property m_information (org.w3c.dom.Element)
[bind] direct marshaller/unmarshaller reference
[bind] Generating code for mapping extras.DomContact1
[bind]
[bind] Wrote 1 files
[bind]
[bind] extras.JiBX_bindingdom1DomContact1_access output file size is 1837 bytes
[bind]
[bind] Kept 3 files unchanged:
[bind] extras.DomContact1
[bind] extras.JiBX_bindingdom1Factory
[bind] extras.JiBX_bindingdom1DomContact1_access1
[bind]
[bind] Deleted 1 files:
[bind] extras.JiBX_bindingdom1DomContact1_access2

BUILD SUCCESSFUL
Total time: 0 seconds

IBM JDKs downloaded from http://www.ibm.com/developerworks/java/jdk/linux/download.html and installed using:

1. sudo aptitude install bc xauth alien
2. sudo alien ibm-java-x86_64-sdk-6.0-1.0.x86_64.rpm
3. sudo dpkg -i ibm-java-x86-64-sdk_6.0-2_amd64.deb
4. sudo update-alternatives --install /usr/bin/java java /opt/ibm/java-x86_64-60/bin/java 1
5. sudo update-alternatives --config java

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dennis Sosnoski added a comment -

Looks like this is an issue with the IBM StAX parser implementation. Unfortunately, StAX is a poorly written specification which left many things open to interpretation - and if one parser interprets the specification differently from another it's going to cause problems for applications.

From the stack trace provided, it looks like the IBM parser is throwing an exception because JiBX is calling the getEncoding() method when the parser is not in the START_DOCUMENT state. Some other StAX parsers will only provide valid encoding information after the parse has been started (at least, that was the case in the past), which is why the JiBX code waits until a start tag has been read before checking the encoding. I'd prefer to see this changed to get the encoding first, if it worked correctly for other StAX parsers.

You might want to pursue this with IBM and see what their rationale is for throwing the exception. I'll keep this open as a JiBX bug in the meantime.

Show
Dennis Sosnoski added a comment - Looks like this is an issue with the IBM StAX parser implementation. Unfortunately, StAX is a poorly written specification which left many things open to interpretation - and if one parser interprets the specification differently from another it's going to cause problems for applications. From the stack trace provided, it looks like the IBM parser is throwing an exception because JiBX is calling the getEncoding() method when the parser is not in the START_DOCUMENT state. Some other StAX parsers will only provide valid encoding information after the parse has been started (at least, that was the case in the past), which is why the JiBX code waits until a start tag has been read before checking the encoding. I'd prefer to see this changed to get the encoding first, if it worked correctly for other StAX parsers. You might want to pursue this with IBM and see what their rationale is for throwing the exception. I'll keep this open as a JiBX bug in the meantime.
Hide
Permalink
Nigel Charman added a comment -

Posted to http://www.ibm.com/developerworks/forums/thread.jspa?threadID=225370. I'll let you know if I hear anything. Thanks.

Show
Nigel Charman added a comment - Posted to http://www.ibm.com/developerworks/forums/thread.jspa?threadID=225370 . I'll let you know if I hear anything. Thanks.
Hide
Permalink
Nigel Charman added a comment -

The responses from IBM are:

"Hi,

A quick look at the javadoc(1) for the XMLStreamReader shows what states the getEncoding() method may be called in. It lists that it is only valid when next has returned START_DOCUMENT and if you try to call methods outside the listed states then a java.lang.IllegalStateException will be thrown.

With out seeing what the code is doing here I can't say what it should be doing, but it looks like the implementation in shipped with IBM Java 6 is following the doc. I would interpret this as you can only call getEncoding() only after a call to next has returned START_DOCUMENT and before the next call to next().

Ben Hardill

(1)http://java.sun.com/javase/6/docs/api/javax/xml/stream/XMLStreamReader.html
"

"Hi,

I checked with the dev team for the StAX parser. Sounds like I was nearly right, except there is no need to call next() first as it is called internally when the XMLStreamReader is created. This means that you can call getEncoding() on the XMLStreamReader before a call to next() or nextTag().

It sounds from Dennis Sosnoski's response that this is how the code used to work but had to be changed to work round problems in other implementations.

Ben Hardill
"

Show
Nigel Charman added a comment - The responses from IBM are: "Hi, A quick look at the javadoc(1) for the XMLStreamReader shows what states the getEncoding() method may be called in. It lists that it is only valid when next has returned START_DOCUMENT and if you try to call methods outside the listed states then a java.lang.IllegalStateException will be thrown. With out seeing what the code is doing here I can't say what it should be doing, but it looks like the implementation in shipped with IBM Java 6 is following the doc. I would interpret this as you can only call getEncoding() only after a call to next has returned START_DOCUMENT and before the next call to next(). Ben Hardill (1) http://java.sun.com/javase/6/docs/api/javax/xml/stream/XMLStreamReader.html " "Hi, I checked with the dev team for the StAX parser. Sounds like I was nearly right, except there is no need to call next() first as it is called internally when the XMLStreamReader is created. This means that you can call getEncoding() on the XMLStreamReader before a call to next() or nextTag(). It sounds from Dennis Sosnoski's response that this is how the code used to work but had to be changed to work round problems in other implementations. Ben Hardill "
Hide
Permalink
Dennis Sosnoski added a comment -

Yes, I was wrong to blame this on StAX ambiguities. I've changed the code to only check the encoding when in the START_DOCUMENT state, and will run some tests on that to see if the change breaks anything (mostly a concern when used in Axis2, since besides the real StAX parser there's also the pseudo-parser implemented through AXIOM to worry about).

Show
Dennis Sosnoski added a comment - Yes, I was wrong to blame this on StAX ambiguities. I've changed the code to only check the encoding when in the START_DOCUMENT state, and will run some tests on that to see if the change breaks anything (mostly a concern when used in Axis2, since besides the real StAX parser there's also the pseudo-parser implemented through AXIOM to worry about).
Hide
Permalink
Alan Stewart added a comment -

I just installed our application on WebSphere 7, which uses the IBM JRE 6 and have encountered the same issue with JiBX 1.1.6a.
Dennis, was your code change been released in JiBX 1.2?
Alann

Show
Alan Stewart added a comment - I just installed our application on WebSphere 7, which uses the IBM JRE 6 and have encountered the same issue with JiBX 1.1.6a. Dennis, was your code change been released in JiBX 1.2? Alann
Hide
Permalink
Dennis Sosnoski added a comment -

Yes, the change is in 1.2. I just ran the complete JiBX build without any problems, using the IBM JDK:

[dennis@localhost v12]$ java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pxa6460sr3-20081106_07(SR3))
IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460-20081105_25433 (JIT enabled, AOT enabled)
J9VM - 20081105_025433_LHdSMr
JIT - r9_20081031_1330
GC - 20081027_AB)
JCL - 20081106_01

I also removed the parser jars from the lib directory of the distribution (so that JiBX would use whatever parser is available from the Java runtime) and ran the examples/starter build and test, again without any problems.

If you can duplicate your problem with a simple project, please attach it to this bug report and I'll investigate.

Show
Dennis Sosnoski added a comment - Yes, the change is in 1.2. I just ran the complete JiBX build without any problems, using the IBM JDK: [dennis@localhost v12] $ java -version java version "1.6.0" Java(TM) SE Runtime Environment (build pxa6460sr3-20081106_07(SR3)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460-20081105_25433 (JIT enabled, AOT enabled) J9VM - 20081105_025433_LHdSMr JIT - r9_20081031_1330 GC - 20081027_AB) JCL - 20081106_01 I also removed the parser jars from the lib directory of the distribution (so that JiBX would use whatever parser is available from the Java runtime) and ran the examples/starter build and test, again without any problems. If you can duplicate your problem with a simple project, please attach it to this bug report and I'll investigate.
Hide
Permalink
Alan Stewart added a comment -

Thanks Dennis. However, I am having some trouble creating an EAR for WebSphere to be able to test it - at least until 1.2 gets into the maven repo. Though I downloaded the 1.2 distribution from Sourceforge and got the jars into my local repo, the 1.2 version of the maven-jibx-plugin was not included and I am getting an error when running the 1.2-beta-1 plugin with the 1.2 binding compiler:
java.lang.ClassNotFoundException: org.apache.bcel.classfile.FieldOrMethod

It was working in 1.1.6a and also the 1.2 binding compiler runs fine in Eclipse with my bindings, so until I can get at the 1.2 version of the maven-jibx-plugin, I won't know if the above issue goes away
Alan

Show
Alan Stewart added a comment - Thanks Dennis. However, I am having some trouble creating an EAR for WebSphere to be able to test it - at least until 1.2 gets into the maven repo. Though I downloaded the 1.2 distribution from Sourceforge and got the jars into my local repo, the 1.2 version of the maven-jibx-plugin was not included and I am getting an error when running the 1.2-beta-1 plugin with the 1.2 binding compiler: java.lang.ClassNotFoundException: org.apache.bcel.classfile.FieldOrMethod It was working in 1.1.6a and also the 1.2 binding compiler runs fine in Eclipse with my bindings, so until I can get at the 1.2 version of the maven-jibx-plugin, I won't know if the above issue goes away Alan
Hide
Permalink
Alan Stewart added a comment -

I was able to get an ear deployed to WebSphere 7 and I can confirm that problem originally reported above is resolved.
I am still getting the ClassNotFound error when using the maven-jibx-plugin 1.2-beta-1 but was able to assemble the war and ear manually after using the 1.2 binding compiler.

Is there some way I can get the source for the 1.2 release version of the plugin to compile locally or will it be in the maven repo soon?
Thanks
Alan

Show
Alan Stewart added a comment - I was able to get an ear deployed to WebSphere 7 and I can confirm that problem originally reported above is resolved. I am still getting the ClassNotFound error when using the maven-jibx-plugin 1.2-beta-1 but was able to assemble the war and ear manually after using the 1.2 binding compiler. Is there some way I can get the source for the 1.2 release version of the plugin to compile locally or will it be in the maven repo soon? Thanks Alan
Hide
Permalink
Dennis Sosnoski added a comment -

Maven updates have been made to the local JiBX repository, so the changes should be picked up by the main repository sometime today.

Show
Dennis Sosnoski added a comment - Maven updates have been made to the local JiBX repository, so the changes should be picked up by the main repository sometime today.
Hide
Permalink
Alan Stewart added a comment -

All works fine now with 1.2. Thanks

Show
Alan Stewart added a comment - All works fine now with 1.2. Thanks
Hide
Permalink
Nigel Charman added a comment -

Confirmed working with 1.2.1

Show
Nigel Charman added a comment - Confirmed working with 1.2.1

People

  • Assignee:
    Dennis Sosnoski
    Reporter:
    Nigel Charman
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: