[jbpm-issues] [JBoss JIRA] Created: (JBPM-2929) ClassCastException after reading serialized variable
ClassCastException after reading serialized variable
----------------------------------------------------
Key: JBPM-2929
URL: https://jira.jboss.org/browse/JBPM-2929
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.4
Environment: Windows XP, Java 6
Reporter: Marcus Klimstra
Related to JBPM-2703.
I have a process definition with two custom nodes, refering to ActivityBehaviour classes
Custom1 and Custom2. Class Custom1 sets a process variable named "bean" of class
Bean, and Custom2 reads and uses this variable:
{code}
public class Bean implements Serializable {
private int value;
public int getValue() { return value; }
public void setValue(int value) { this.value = value; }
}
public class Custom1 implements ActivityBehaviour {
public void execute(ActivityExecution execution) throws Exception {
Bean bean = new Bean();
bean.setValue(42);
execution.setVariable("bean", bean);
}
}
public class Custom2 implements ActivityBehaviour {
public void execute(ActivityExecution execution) throws Exception {
Bean bean = (Bean)execution.getVariable("bean");
if (bean.getValue() != 42) {
throw new Exception("Value must be 42!");
}
}
}
{code}
All these classes were added to the deployment using
addResourcesFromZipInputStream/addResourceFromInputStream. So far this works fine.
However, when I put a task node between custom1 and custom2 (apparently causing the
variable to be serialized?), things go awry:
{code}
java.lang.ClassCastException: [...].Bean cannot be cast to [...].Bean
at [...].Custom2.execute(Custom2.java:6)
at
org.jbpm.pvm.internal.wire.usercode.UserCodeActivityBehaviour.execute(UserCodeActivityBehaviour.java:42)
at org.jbpm.pvm.internal.model.op.ExecuteActivity.perform(ExecuteActivity.java:60)
at ...etc...
{code}
So it seems that there are two Bean-classes, loaded by different classloaders. I've
traced this problem to the DeploymentObjectInputStream, which creates a new
DeploymentClassLoader each time it enters the catch-clause. Since the second Bean-class is
loaded by a different classloader, it is incompatible with the first.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira