[jbpm-issues] [JBoss JIRA] Commented: (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 Fix For: jBPM 4.x Attachments: JBPM-2929-fix.patch, JBPM-2929-test.patch 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.