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....
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.
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 ?
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.