[jbpm-issues] [JBoss JIRA] Updated: (JBPM-2954) SharedProcessClassLoaderFactory: problematic class loader caching for non-deployed process definitions

SharedProcessClassLoaderFactory: problematic class loader caching for non-deployed process definitions ------------------------------------------------------------------------------------------------------ Key: JBPM-2954 URL: https://jira.jboss.org/browse/JBPM-2954 Project: jBPM Issue Type: Bug Security Level: Public(Everyone can see) Components: Runtime Engine Affects Versions: jBPM 3.2.7 Reporter: Mauro Molinari Assignee: Alejandro Guizar Fix For: jBPM 3.2.10 When you are working with non-deployed process definitions and you want to get a reference to their own process class loader, if these two process definitions share the same name the class loader of the first is returned for the second too by org.jbpm.instantiation.SharedProcessClassLoaderFactory. This is because org.jbpm.instantiation.SharedProcessClassLoaderFactory.getProcessClassLoader(ProcessDefinition) determines if the same class loader had been requested before by using: - the id of the process definition, if available (i.e.: for the deployed process definitions) - the hashCode of the process definition otherwise (i.e.: for non-deployed process definitions) The problem is that, if the process definition is not deployed, the resulting hashCode is a function of just its name. So, the two process definitions mentioned above are treated like they were an only one, because they share the same name. I think a more correct approach is to use System.identityHashCode() for non-deployed process definitions, because in that case it's reasonable to consider a process definition better identified by its instance rather than by just some of its characteristics. This is the approach I followed for my resolutions of the problem I described in my comments to bug JBPM-2428 and it works well. Maybe a more correct and full solution could be to calculate the hashCode of a non-deployed ProcessDefinition taking into account also its FileDefinition, not only its name and version. In this way the result of org.jbpm.graph.def.ProcessDefinition.hashCode() would be consistent for all of its uses. However, it may be hard to implement an efficient hashCode for FileDefinition...