Ronald
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
Fair enough...
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
Hauch,
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
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.
View the original post :
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
View the original post :
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
