with all these kinds of new reflection using frameworks with custom classloader things, the processclassloader (used for versioning mainly) becomes less and less usefull (imo).
So my suggestion would be to try it without loading any classes that are in the processarchive. Put all in jars on the classpath but jou might run into https://jira.jboss.org/jira/browse/JBPM-1148 then....
Thanks for your reply.
I'm not to happy about the suggestion, however.
That would require a restart with every change in objects (internal to jbpm) - and might cause problems if a class used in a long running workflow changes.
Yep... correct... but my suggestion was just to check if it works then, so we have a more narrow path to search for the real problem... and maybe rethink (redesign?) the class versioning in relation to processdefinitions
So I did as suggested: copied my objects using jaxb to lib, which worked fine.
This is however an unacceptable solution (as mentioned above), and the only purpose was to narrow down the problem.
So back to start: any suggestions how to make jaxb work with classes loaded with the jbpm classloader?
I think the first thing to do is to make a jira issue for this. This does not solve your problem, I know, but it puts it on the radar. A complete yet simple example would help a lot.
This is such a fundamental thing (the classloader in relation to other frameworks) that I suspect that you will not get any help from the community. Not that they do not want to, but for some that had kind of similar issues, it was not a big deal to do it differently. The core developers are the ones that can either help you with some suggestions, fix it or whatever.
Thanks for your help.
There is already a jira on this issue - I just couldn't get the described fix to work (see the first post).
My hope was that somebody actually had tried the fix, and was able to help me.
I will find another way to solve the problem (probably using xStream, xmlBeans or equivalent).