Eric D. Schabell: jBPM from the trenches - a jBPM CustomClassLoader

Thursday, December 25, 2008

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.
Posted by at
Labels:

2 comments:

  1. Ronald van Kuijk04 January, 2009 23:33

    Eric,

    Take a look at this: http://www.bpm-guide.de/2008/10/16/jbpm-deployer-for-jbpm-in-enterprise-environments/ Now that is really interesting..... May I ask what the reason is that you cannot upgrade jBPM but can run an adapted version? Or is that just in a test environment?

    ReplyDelete
  2. Eric D. Schabell05 January, 2009 22:00

    I really liked the link you posted, but there are lots of things we:

    - don't have (ESB's, EAR's)
    - may not have (ESB's)
    - can't do, yet (upgrade)

    But for some reason I am able to convince them to allow a very simple upgrade (single class) for now. I scratch my head often in my work world, believe me.

    There is more behind the scenes going on. In 2009 we are starting our jBPM Team with one of the first issues being to upgrade. We want to define this as a core component in the solution architecture.

    Meet and Greet?
    ==============
    Maybe I can entice you to drop in to our shop for a coffee/tea and a tour of our infrastructure? Want to come and tell us more about your work / experiences with jBPM?

    You would be welcome anytime! ;-)

    ReplyDelete

Note: Only a member of this blog may post a comment.

Subscribe to: Post Comments (Atom)