org.jbpm.JbpmException: couldn't deserialize object

[camunda]

Hi!

I experienced a problem: If you deploy your business object classes only with jBPM (so you don't have it on the classpath), you get an exception when loading these objects (ClassNotFoundException).

I added detailed information to this on this related bug, maybe it should be reopened?
http://jira.jboss.org/jira/browse/JBPM-1024

Or we just say, domain classes have to be on the classpath?

What do you guys think?

Cheers
Bernd

[kukeltje]

afair, it is also related to where the hibernate classes are loaded from. So they should be somewhere your hibernate classes can find them. I think it is hard to 'fix', but I'm not sure. Making everything versioned is probably hard.

[camunda]

I agree with you... And since it shouldn't be a normal use case (in this case it was just a demonstration example where you keep it as simple as possible), I think we can leave it like it is...

[aguizar]

I think it is worth fixing. It is completely at odds with common sense that you can put action handler classes in your process archive, but not variable value classes. It does however imply a change in the Converter class, or an inelegant (but working) fix as shown in JBPM-1024.

I'd propose to keep the fix on jBPM 3.2.x and change the Converter.revert() method on jBPM 3.3.

[tom.baeyens]

still hibernate will not know of the class.

so i agree with bernd and ronald. we should document it as a known limitation.

[kukeltje]

Can we make hibernate use the processclassloader if hibernate jars are in deployed in the war or ear? Probably not, otherwise you guys would have proposed this (I'm just a hibernate noob)

[tom.baeyens]

probably by making it the context classloader. but i can't oversee all the consequences of that. i only expect there are a lot of those :-(

[aguizar]

still hibernate will not know of the class.

Why does hibernate have to know about the process classes? As I see it, hibernate only needs to provide the byte array. It is SerializableToByteArrayConverter's responsibility to read an object from the bytes. A subclass of ObjectInputStream may be required to bring the ProcessClassLoader into the equation without touching the context class loader.

[tom.baeyens]

this topic is about "business object classes" the hibernatable user objects that are stored in the variables through as a reference mapped with hibernate's "any". it's not about serializing the object.

[camunda]

Hi Tom,

Sorry, but we started this thread indeed with just serializing objects into blobs.

My use case was: Get a sample running with the web console. There I added some "business objects" to the process by an action handler. These objects were just deployed together with the process definition. When I arrived in a task form I got the exception, because the class cannot be found for deserializing (and the root cause isn't shown in the console, so it wasn't straight forward to figure out what was the problem). It wasn't a hibernate class and not the any association...

With a hibernate class IT MUST be on the classpath, because it is in the hibernate mapping, no problem here I think...

[aguizar]

Bernd and other folks' examples in JBPM-1024 are about storing serialized objects in the variables, which is what I think is worth addressing. These objects cannot be deserialized if the class files are only present in the process archive.

Now I understand what you meant by hibernate not knowing of the class, but hibernatable objects are not what JBPM-1024 is about. As Ronald points out, fixing the issue for hibernatable classes is harder. I don't know how to override hibernate's class loader except for overriding the context class loader, which will certainly open a can of worms.

I committed a unit test (CustomSerializableVariableDbTest) which shows that JBPM-1024 affects 3.2.2 but not the current CVS head. Fady fixed it with a hack on VariableInstance, which goes to prove that a hack is faster than discussion ;-)

[tom.baeyens]

sorry, my bad.

now that you mention it, it does ring a bell that we looked at this some time ago.

let's release the hacky fix and see if it stands.

Fady fixed it with a hack on VariableInstance, which goes to prove that a hack is faster than discussion ;-)

indeed :-)

but be very carefull with classloader hacks. very often they backfired on me and i spend lots of time afterwards fixing it in different environments.

[kukeltje]

which will certainly open a can of worms.

Then just fry them and put a little chilisaus on them?