1 Reply Latest reply on Feb 21, 2007 10:25 AM by Arjan van Bentem

    Deploying recursive process definitions

    Olivier Debels Newbie


      When playing around with jpbm I stumbled onto this problem for which I can't find a decent solution (to be honest I think it cannot be handled with my version of jbpm - which is 3.1.1).

      The problem is as follows:
      When deploying a process definition A which has another process definition B as sub process (using processState node), you need to first deploy a new version of B before deploying A. Otherwise A will still be linked with an older version of B.

      The reason for this behavior is that the link with the subprocess is resolved at deployment time, so if A is deployed first it will be linked with the existing (older) version of B in the database. Deploying B afterwards will not resolve this, so A is stuck in this case with the older version of B.

      That's OK for me. Furthermore the resolving behavior can be tweaked by providing a custom SubProcessResolver.

      Suppose that you have a recursive process definition, i.e. the process definition A has itself as subprocess. If I Deploy A, it will resolve the subProcess, which will make a link to the older deployed version of A! And this is not what we want, it must refer to the new deployed version!!

      Same problem arises with other recursive process definitions f.e. A containing B, containing C which contains A again.

      When looking at the code I see that there is something which handles the case when a recursive process definition is deployed for the first time (ProcessState.java).

      // in case this is a self-recursive process invocation...
       if (subProcessDefinition==null) {
       String subProcessName = subProcessElement.attributeValue("name");
       if (subProcessName.equals(processDefinition.getName())) {
       subProcessDefinition = processDefinition;

      This will work since no A is deployed yet, but as soon as an A is deployed the subProcessDefinition will be filled in by the resolver (with a wrong old deployed A).

      How to solve this problem? Is there a way to deploy A and stalling the resolution of subprocesses?