Hi,we are using jBPM in conjunction with OSGi on jBoss Appserver and had problems with the classloading of jBPM. So we looked at the Source Code of ClassLoaderUtil.java and found out that you are actually not using the context class loader to for classloading, which was the cause for our problems. For my understanding this is common practice for libraries used in J2EE Environments. There already is a comment in current ClassLoaderUtil implementation stating that class loading could be made configurable:

We implemented a patch that reflects the proposal of this comment. It enables jBPM to use the context class loader or to plug in a 'custom' classloader whose class name is defined by another system property. Classloading with the current classloader is the default, if no system property is set. We would like to provide this code to the community. Please give me feedback what you think about this.

not specifically... if you make the changes in the code and post them here or attach them to a jira issue that is fine to. CVS access is only needed if you want real committer access for more than one patch

I wanted to use it for an own problem with classloading (and I can also commit it back to jbpm after it works correctly) but have the problem, that this is leading to and endless loop, since the classloader is already needed to load the jbpm.cfg.xml in the JbpmConfiguration (InputStream jbpmCfgXmlStream = ClassLoaderUtil.getStream(resource);).

Exception StackTrace:

at org.jbpm.util.ClassLoaderUtil.getClassLoader(ClassLoaderUtil.java:50)
at org.jbpm.util.ClassLoaderUtil.getStream(ClassLoaderUtil.java:83)
at org.jbpm.JbpmConfiguration.getInstance(JbpmConfiguration.java:279)
at org.jbpm.JbpmConfiguration.getInstance(JbpmConfiguration.java:257)
at org.jbpm.JbpmConfiguration$Configs.getObjectFactory(JbpmConfiguration.java:418)
at org.jbpm.JbpmConfiguration$Configs.hasObject(JbpmConfiguration.java:426)
at org.jbpm.util.ClassLoaderUtil.getClassLoader(ClassLoaderUtil.java:50)