JiBX also supports limited runtime binding of class files. This adds runtime overhead as compared to using the binding compiler directly during the build process, but can be convenient when you're experimenting with different binding definitions or going through repeated build-test cycles. At present, runtime binding only works with classes that are present in the classpath as individual class files (not in jars). It's also not designed for use in controlled environment such as servlet engines or application servers.
To use the runtime binding support, you need to execute the
org.jibx.binding.Run
class (from /lib/jibx-bind.jar) as the
main class when starting the JVM, in place of whatever main class you'd normally
give as the target. You can pass one or more binding definition files as command
line arguments to this class, along with the name of your application main class
and any command line arguments expected by your program. For example, if you
normally run your application using the command line:
java -cp . com.myco.package.App arg1 arg2
and your JiBX installation is at /home/dennis/jibx, you'd run the application using runtime binding as follows (in a single line, shown split here only for formatting):
java -cp .:/home/dennis/jibx/lib/jibx-bind.jar org.jibx.binding.Run -b binding.xml com.myco.package.App arg1 arg2
This tells the JVM to start execution with the org.jibx.binding.Run
class, which will then use its own classloader to load your application classes,
after first modifying the classes read from disk to reflect the binding.xml
binding definition. Once the binding has been processed, JiBX will transfer
control to your application main class (in this case,
com.myco.package.App
), passing the command line arguments just as
if your application were executed directly from the command line. Note that
this is the Unix/Linux version of the command line; if you're running
Windows you'll need to reverse the slashs and use ';' instead of ':' as a path
separator character.
The runtime binding code supports several different ways of specifying the binding definition file or files to be used for your application. The first, and most direct, approach is to supply one or more -b file-path argument pairs before your application main class name on the command line. This is the approach used in the above example, with a single binding definition. To use multiple binding definitions this way, you need to give the -b argument before each individual file path.
The second approach is to give the path to a simple text file (not an XML file) that gives a list of binding definition file paths, with one binding file per line. This uses the -l argument as a flag, so if the binding file list is in a file named bindings.txt you could use the following command line to run your application with the named bindings (on Unix/Linux; if you're using Windows or MS-DOS you'll need to reverse the slashs and use ';' instead of ':' as a path separator character):
java -cp .:/home/dennis/jibx/lib/jibx-bind.jar org.jibx.binding.Run -l bindings.txt com.myco.package.App arg1 arg2
The third way is to give the binding definition(s) as resources loaded from the classpath, rather than as actual file paths. The advantage of doing things this way is that the binding definition(s) can be kept with your actual class files (or with the source files, and copied during build to the same directory as your class files). This uses the -r argument as a flag for each binding definition to be loaded as a resource, followed by the actual resource path. For example, if your binding file is kept with your main class you could use a command line of this form to run it:
java -cp .:/home/dennis/jibx/lib/jibx-bind.jar org.jibx.binding.Run -r /com/myco/package/binding.xml com.myco.package.App arg1 arg2
All three of the above techniques can be used in any combination on the command line (though it's difficult to imagine actually needing to do so!).
Finally, you can instead use implicit binding definition resources. When
you do this you don't need any command line arguments for JiBX (though you still
need to specify the org.jibx.binding.Run
as your main class) except
for the application main class name and any arguments to be passed to that
class:
java -cp .:/home/dennis/jibx/lib/jibx-bind.jar org.jibx.binding.Run com.myco.package.App arg1 arg2
In this case JiBX goes through the following sequence of steps to find the binding definition resource(s) to be applied: