[jbpm-issues] [JBoss JIRA] Commented: (JBPM-2954) SharedProcessClassLoaderFactory: problematic class loader caching for non-deployed process definitions
[
https://jira.jboss.org/browse/JBPM-2954?page=com.atlassian.jira.plugin.sy...
]
Alejandro Guizar commented on JBPM-2954:
----------------------------------------
To summarize, you are requesting that the SPCLF supports multiple in-memory process
definitions with the same name. The question is why are they sharing the name in the first
place. Are they different versions of the same process (1), or are they unrelated
processes (2)?
In case (1), you could simply call setVersion(int) and be done. Case (2) is inconsistent
with the persistent notion of versioning. The engine operates under the assumption process
definitions having the same name form an evolutionary sequence.
On the other hand, it can be argued that if the version of a process definition is -1
(meaning "unknown" or "undeployed") it should not be used in either
hashCode() or equals(). In effect this would mean:
public int hashCode() {
if (name == null || version == -1) return super.hashCode();
// ...
}
public boolean equals(Object o) {
// ...
return name != null && name.equals(other.getName())
&& version != -1 && version == other.getVersion();
}
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
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...
--
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