Feature Incubator for Open ESB
This page holds documentation on experimental features that we have incorporated into the Java SE release of Open ESB. We would love to here your feedback on these projects as well as help/suggestions for future incubator projects. Just drop an email to the dev
list for Project Open ESB
Component Classpath Extension Mechanism
When running on the Java SE release of Open ESB, many components find that they have hidden dependencies on jars that are available in the platform class loader of their favorite runtime (e.g. /glassfish/lib). Of course, components with these dependencies fail to run under Java SE, because there is no way to drag the extra libraries into the component's runtime classpath without repackaging the component to include them all directly. Even if you go with the repackaging route, it may be desirable for multiple components to share the same library (particularly in a lightweight Java SE distribution).
To address this issue, we have introduced an extension mechanism that allows the user to add jars/classes/resources to the classpath of all components in the runtime. The way this is done is by inserting an additional extension class loader between the shared JBI class loader and the runtime class loader (for more info on class loading details in Open ESB, see Mark White's excellent blog
on the subject). The extension class loader sucks up anything in the lib/ext directory of the installation root (e.g. /jbise/lib/ext), so all you have to do is copy your dependencies into this directory and start the server.
A few notes on this feature:
- All components delegate to the same extension class loader, so every component will have visibility into what is in lib/ext.
- The lib/ext directory does not exist in the initial install, so you have to create it if you want to take advantage of the extension mechanism.
Running the HTTP BC in Java SE
Our HTTP Binding Component leverages a lot of the platform infrastructure in Glassfish, which makes for a great feature set, but also exposes us to portability issues in other containers. Luckily, the two most important pieces the HTTP BC uses in Glassfish, JAX-WS and Grizzly, run just fine out of Glassfish too. Well, if they can do it, we can too! This incubator project represents a proof of concept for running the HTTP BC in Java SE, demonstrating that it can in fact be decoupled from the Glassfish platform. In theory, you should be able to run the HTTP BC on any other platform if it runs on Java SE. I'll leave that as an exercise for the reader. :-)
- Extract jar in location of your choice (instructions assume /).
- Create extension directory (mkdir /jbise/lib/ext).
- Download dependencies and copy into extension directory:
NOTE: This is necessary because the HTTP BC cannot see jars in the runtime class loader, which is where jars from the lib directory are loaded. This will not affect the core runtime, since the extension class loader is the parent of the runtime class loader.
- Move JAXB jars (jaxb-impl.jar and jaxb-api.jar) from /jbise/lib to /jbise/lib/ext .
- Start JBI framework (java -jar /jbise/lib/jbise_framework.jar)
This was an outside-in effort, in that it takes advantage of the classpath extension mechanism to deliver dependencies to the HTTP BC in the same way that Glassfish provides them today (i.e. through a parent/platform class loader). The next thing we need to look at is if all of these dependencies are really necessary and whether any of them should be packaged directly inside the HTTP BC component archive. Watch this space for new developments.