Q. What does it mean when I get
java.lang.IncompatibleClassChangeError thrown while trying to
compile a binding?
A. This is caused by having an older version of the Apache BCEL library somewhere
in your classpath ahead of the JiBX libraries. It usually occurs when using the
Ant binding task, because Ant often includes an XSLT library named
xsltc.jar in the classpath, and this library uses BCEL. It could also
occur outside of Ant if you have xsltc.jar in your Java installation's
/lib/ext directory. xalan.jar can also cause the same problem, and
for the same reason.
Q. What does it mean when I get
org.jibx.runtime.JiBXException: Unable to access binding information for
class ... thrown while trying to run my application with JiBX?
A. This means your class files (or at least the one for the class you asked the
org.jibx.runtime.BindingDirectory to look up) haven't been processed
by the JiBX binding compiler. Check your build process and make sure you're
doing the binding compiler step. This problem has been known to occur in some
IDEs when the IDE uses a different location for compiled class files from what
is used by an Ant build script or manual build process.
Q. Why do I get a java.lang.NullPointerException
when I try to marshal a document?
A. The most likely cause is that you've got a null value
for an object that's not marked as optional in the binding definition. JiBX
trusts what you tell it, so if you don't say an object property is optional the
generated code won't check for a null. To isolate the cause of this
type of problem, look through the stack trace (starting at the top) for the
first class name from your code. This will normally be the class that contains
the null property. You can then verify the binding definition for that class. If
it's not obvious which property is causing the problem, add a pre-get
method to that class for debugging purposes which checks if any of the
non-optional object properties used by the binding are null
(throwing an exception when it finds a null, with any added
information you want to see). This will let you find out all the details of the
problem so that you can fix either the code or the binding, whichever is wrong.
Q. How can I control the package used for the classes
generated by JiBX (including the binding factory class or classes, and the
JiBX_MungeAdapter.class)?
A. You can control the package used for the binding factory class for a
binding by using the package attribute of the binding element. The
JiBX_MungeAdapter.class is only generated if needed. When needed,
it's created in the package of the first mapping class which is both
modifiable (a class defined in its own file, rather than in a jar file) and not
an interface. If you need this to be in a particular package (as may happen when
you're binding classes that have package access), include a mapping for
one of the classes in this package before any other mappings in the
binding definition, and if you're compiling more than one binding make the one
with this mapping the first one in the list. If necessary, you can
compile bindings in multiple sets to get more than one
JiBX_MungeAdapter.class in different packages. This only works if
you have bindings with no overlapping packages, though - otherwise running the
binding compiler twice with different sets of bindings will cause information
from the first set to be lost.
Q. Does JiBX work with other bytecode modification
techniques, such as JDO or Hibernate?
A. Yes, JiBX works well with other frameworks which build on bytecode
modification. In the case of JDO you'll generally need to run the JiBX binding
compiler before you run the JDO bytecode enhancement, since the latter may need
to intercept field accesses from the JiBX code. In the case of Hibernate this is
not an issue, since Hibernate