Initialise thread context classloader

[camunda]

Hi.

I am working on https://jira.jboss.org/jira/browse/JBPM-1448 (jBPM does not initialize thread context classloader).

First of all, why I want to do this: This enables you to put Interfaces or other stuff used in your action classes in the par, so they end up in the database. Because the ProcessClassLoader will become ContextClassLoader it is used to load everything correctly...

But this is only half the way I want to go. Image you put jbpm in your app-server (or ESB) once, but have different applications (ear, esb, ...) using it. Now I write an own small MBean, which is a registry where processes register which class loaders are responsible for "their" action classes. My own ProcessClassLoader now also looks in this registry and by doing so, it can even load action classes or other stuff correctly from the right EAR, even if a process was maybe started by the web-console, not knowing the ear... But more on this idea later.

Back to setting the ContextClassLoader. My approach to implement it is adding this code

ClassLoader oldCl = Thread.currentThread().getContextClassLoader();
try {
 Thread.currentThread().setContextClassLoader(
 ClassLoaderUtil.getProcessClassLoader(processDefinition));

 .... existing code ...
}
finally {
 Thread.currentThread().setContextClassLoader(oldCl);
}

to the following methods:
- Action.execute
- Decision.execute
- TaskController.initializeVariables
- TaskController.submitParameters
- AssignmentHandler.performAssignmentDelegation

On all these places I have the ProcessDefinition on hand, so it is possible to do... These are all places I found where the ProcessClassLoader is used and all Delegation use cases I remembered. So it is not too much work to do and consistent overall in jBPM (not like the proposed workaround to build an own base action class where the context class loader is set).

What do you guys think?

Cheers
Bernd

[camunda]

Hey guys, any comments on this? Thoughts?

I would like to add it to the jbpm 3.3.0 release, so I aks before the Jira freeze ;-) Possible? Can somebody assign it to that release please?

I would take this task and do it, since it is required in a current project and a good improvement too....

[camunda]

And I would like so see the ClassLoader-Problem fixed in 3.3.0: https://jira.jboss.org/jira/browse/JBPM-1148, see also http://www.jboss.com/index.html?module=bb&op=viewtopic&t=130732.Can somebody assign it to that release?

I think it is a good opportunity to change this in a major release number change!

I would also volunteer for it.

[camunda]

URLs from last post correctly:
https://jira.jboss.org/jira/browse/JBPM-1148
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=130732

[tom.baeyens]

Bernd,

your proposal to set the context classloader around all the user code places is ok. it would be great if you could do that.

i'll review and back you up in case that turns out to be necessary.

but the only part i didn't get yet was the loading classes from the dedicated ear files. if i understand correct, it is an optional addition to this context classloader fix. let's discuss that separately. in the meantime, you can go ahead and contribute this functionality of setting the context classloader.

what kind of tests for this did you have in mind ?

[camunda]

Yeah, the ContextClassLoader is an own problem which can be solved seperatly and I will start on it next week.

The other stuff with the jbpm.deployer is an additional feature (but which needs the ContextClassLoader to be fixed to work correctly).

For testing: Hmm, good question. Do you have something in mind? the existing test cases should cover if delegation classes are still executed correctly, but ContextClassLoader issues may be more a problem in complex environments?

Maybe Thomas has good thoughts on this?

The ideas with the jbpm.deployer also will get interesting to test, I thought about deploying different EAR versions in parallel and test the used classloader and that stuff in the action classes. But it will definitly require a running JBoss... But this will be only part of the Enterprise version anyway... We can also discuss that on friday, but it is indeed independant from the ContextClassLoader problem.