I found a solution to this based on another post and that was to do the following
ProcessState superState = (ProcessState) superDef.getNode("process-state1"); superState.setSubProcessDefinition(subDef);
This seems realy yuk. If the parent process knows that it has a sub-process why can't it just load the definition. At the very least you could have the xml location as an attribute of the subProcess node.
I disagree that it is 'yuk'. You mention yourself that you (want to try to) run *outside* of the container, container being the jBPM 'engine' via a jbpm 'context' (I doubt you will succeed). If you deploy a processdefinition (even just to an in memory db), the container does resolve dependencies for you.
Why should I need a database (even an in memory one) to run short running processes? If you specified a subprocess and resolvable process xml then everything should be sweet without a database.
I don't say you need a database to run things, I just say that the jbpm container resolves subprocess dependencies when you *deploy* them. Since you do not deploy them, there is no resolver and you have to associate the two yourself.
the 'I doudbt you would' success was indeed a bit harsh and not directed at you, but a remark in general which I now think is not completely valid. What I wanted to express is why not just associate the two via an api if you know they are related instead of trying to make resolvers or whatever.