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
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
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
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: