Uploaded image for project: 'jBPM'
  1. jBPM
  2. JBPM-2954

SharedProcessClassLoaderFactory: problematic class loader caching for non-deployed process definitions

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • jBPM 3.2.10
    • jBPM 3.2.7
    • Runtime Engine
    • None
    • Hide

      Create your own implementation of org.jbpm.instantiation.ProcessClassLoaderFactory that offers the same functionality of the provided org.jbpm.instantiation.SharedProcessClassLoaderFactory but that does not suffer from this problem and configure jBPM to use it.

      Show
      Create your own implementation of org.jbpm.instantiation.ProcessClassLoaderFactory that offers the same functionality of the provided org.jbpm.instantiation.SharedProcessClassLoaderFactory but that does not suffer from this problem and configure jBPM to use it.
    • Hide
      • configure jBPM so that it uses the default SharedProcessClassLoaderFactory
      • prepare a PAR containing a process definition with name "TEST" and a "test.txt" file inside its classes folder it; let the contents of this file be "test1"
      • prepare another PAR containing another process definition with name "TEST" and a "test.txt" file inside its classes folder; let the contents of this file be "test2"
      • load each PAR into two ProcessDefinition instances with ProcessDefinition.parseParZipInputStream(ZipInputStream)
      • DO NOT deploy these two process definitions
      • try to get the class loader for the first and the second process definition with org.jbpm.JbpmConfiguration.getProcessClassLoader(ProcessDefinition)
      • the two class loaders returned are the same one, that of the first process definition; in fact, if you try to do a getResourceAsStream(String) of /test.txt and you read its contents, you'll read "test1" for both process definitions
      Show
      configure jBPM so that it uses the default SharedProcessClassLoaderFactory prepare a PAR containing a process definition with name "TEST" and a "test.txt" file inside its classes folder it; let the contents of this file be "test1" prepare another PAR containing another process definition with name "TEST" and a "test.txt" file inside its classes folder; let the contents of this file be "test2" load each PAR into two ProcessDefinition instances with ProcessDefinition.parseParZipInputStream(ZipInputStream) DO NOT deploy these two process definitions try to get the class loader for the first and the second process definition with org.jbpm.JbpmConfiguration.getProcessClassLoader(ProcessDefinition) the two class loaders returned are the same one, that of the first process definition; in fact, if you try to do a getResourceAsStream(String) of /test.txt and you read its contents, you'll read "test1" for both process definitions

    Description

      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...

      Attachments

        Activity

          People

            aguizar_jira Alejandro Guizar (Inactive)
            mauromol_jira Mauro Molinari (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: