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.