DeploymentAdaptor: duplicated process deployment since commi

[sny]

Hey,

I've found a problem with the JBoss deployment code in jBPM4.
It has been introduced in commit 4753 which added forms support via freemarker .ftl template files.

A change was made in the DeploymentAdaptor's deploy() method to add all resources from the given zip input stream (instead of just the specified process descriptor .jpdl.xml given in the DeploymentMetaData).

Index: DeploymentAdaptor.java
===================================================================
--- DeploymentAdaptor.java (revision 4752)
+++ DeploymentAdaptor.java (revision 4753)
@@ -23,6 +23,7 @@

 import java.io.File;
 import java.util.List;
+import java.util.zip.ZipInputStream;

 import javax.naming.InitialContext;
 import javax.transaction.SystemException;
@@ -59,7 +60,8 @@
 File deploymentFile = new File(deploymentName);

 long deploymentDbid = repositoryService.createDeployment()
- .addResourceFromUrl(deploymentMetData.getProcessDescriptor())
+ .addResourcesFromZipInputStream(new ZipInputStream(deploymentMetData.getWatch().openStream()))
+ //.addResourceFromUrl(deploymentMetData.getProcessDescriptor())
 .setTimestamp(deploymentFile.lastModified())
 .setName(deploymentName)
 .deploy();

This was apparently done to add the .ftl templates to the deployment but has the (IMHO unintended) consequence of also adding ALL processes from the archive.

In combination with the way the .bar is deployed in JBoss, this results in multiple deployments (DeploymentAdaptor called n times for n process descriptors in the .bar) each including all the processes (ie: a .bar with 4 .jpdl.xml files will result in 4 deployments each including all 4 processes).

Also, I found the deployer to not really consider the timestamp of the .bar. When starting/stopping the server, it will undeploy the processes (which suspends them as indicated in jira issue JBPM-2242) but instead of reactivating them it will redeploy them which then results in another n deployments.

I know, two issues in one post, but they are kind of related.

Regards,
Marko

[kukeltje]

All processes from the archive should be added. That is the intended behaviour. Can be related subprocesses or multiple processes related to one application. What is going wrong in your situation?

Second one does not happen if you use versioning IN the processdefinition afaik. Timestamps are dangerous for these.

[sny]

Well, yes, of course all should be deployed, what happens, however, is that they are added tp each deployment which makes each appear n times.

The JBoss main deployer picks up the .bar, finds n .jpdl.xml files in it, goes and calls the jBPM deployer n times, which for the reason detailed in the OP will deploy all n processes for every call. Hence you get n x n processes.
This was clearly not how it worked before the quoted patch and I am not sure it is supposed to do so now.

Regards,
Marko

[camunda]

Hi Marko.

The Deployer is still unde development. There were some issues to discuss and therefor it is in some unfinished state. I will come back to it asap, but don't know exactly when this will be :-(
The problem of not deploying it multiple times is not completly easy to solve, but I have some possible solutions in my mind and on an oldschool piece of paper in my office ;-)

Cheers
Bernd

[sny]

Heh, OK, I know it's still being worked on but wanted to bring this specific point up. I first thought about filing a jira issue, but then decided against it and posted here instead.

FWIW, I worked around it in my local version by adding a flag to the addResourcesFromZipInputStream() method to tell it to NOT add any .jpdl.xml files. Then I included both calls in the deploy() sequence so it now adds all resources except the process descriptors and then adds the one process descriptor it has been invoked for.

Regards,
Marko

[kukeltje]

Marko,

Explicit versioning of the jpdl.xml files should prevent multiple deployments as I mentioned in my initial reply. Could very well be that that is not in place yet (and that Bernd has some ideas in this direction)

btw, *anything* not in the user guid but in the dev guide is still under development. So you could run into other issues as well as you use these