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 only uses runtime bytecode enhancements; however,
you will generally need to have JiBX use get/set methods rather than directly
access fields with working with Hibernate.
Q. Which JDK versions are supported by JiBX?
A. The JiBX runtime and binding compiler have been tested on JDK versions
1.3-1.6. There are some minor differences on the build
for JDK 1.3, but these differences do not effect the runtime operation. The new
JiBX tools introduced with the 1.2 release () require JDK 1.4.1 or higher.
Q. Is there a DTD or schema available for the binding
definitions?
A. The /docs directory of the distribution includes both a DTD
(binding.dtd) and an XML schema (binding.xsd) for the binding
definitions. These will hopefully be kept up to date, but the definitive
reference for the binding definition format is the HTML
documentation.
Q. I want to use JiBX data binding with Axis2. How can
I learn more about this combination?
A. There's an Axis2 subproject page on this site which
provides some basic information and links, and that page will be expanded to
include more information for the upcoming JiBX 1.2 beta release. Beyond that, I offer an
Apache Axis2 training
class that covers all three major data binding frameworks supported by Axis2,
including JiBX. Depending on your needs, the class can be customized to provide
more in-depth coverage of the JiBX framework, and can also include coverage of the
JiBX/WS web services support. This class can also be combined with my
SOA developers training
class for organizations that are moving to a SOA structure and want to use
JiBX in this context.
Q. Where can I find more information or examples?
A. There are
searchable archives for the JiBX mailing lists, at the Mail Archive (jibx-users
and jibx-devs)
and MARC: Mailing List Archives at AIMS
(jibx-users,
jibx-devs, and
jibx-cvs). You're
welcome to ask questions on the mailing lists (especially the jibx-users
list), but it's always a good idea to check the archives first before asking a
usage question, just in case it's already been discussed. The archives are
public, but you must subscribe to each list before you can post to that list.