jBPM from the trenches - a jBPM CustomClassLoader

My partner in crime has already mentioned this over on his site, so you can read what deMaurice posted there for the details. I will just bring you up to date on our running story of the jBPM process rework:

A jBPM Custom Class Loader
As you all know from reading previous posts, we are running on jbpm-3.1.4, which is lacking in some of the fantastic features provided by v3.3.x or v4. Within our current execution infrastructure we have been also limited to running only one jbpm engine for all deployed processes. Combined with these restrictions, our SOA layer is offering backwards compatibility by deploying 3 versions of services. Each interface update on a Service leads to a new version.
Current processes are all running on exactly the same version in the SOA layer, as class loading has never been that optimal with jbpm-3.1.4. Last week, deMaurice and I set out to implement this in our own version of jbpm-3.1.4. We ended up updating the code in exactly 4 places:

1. in the jbpm core utils we had to update the ClassLoaderUtil class to the one in jbpm-3.3.0.GA to support the selection of a custom class loader.
2. added a new system property to the jbpm.cfg.xml file jbpm.classloader='custom' and provide our own class loader property in jbpm.classloader.classname='our-custom-class-loader'.
3. create a custom configuration file containing api and end-point entries per deployed process.
4. write a class loader that is used as our custom entry.

The most interesting part of this exercise was how simple it turned out to be to get it in a single configuration file.

Feel free to contact either me or deMaurice for details should you be looking to do something similar.