Red Hat Bugzilla – Bug 778536
Introduce jbpm deployer
Last modified: 2010-01-22 12:37:54 EST
Date of First Response: 2008-11-14 05:23:03
In the AS/ESB environment, and especially in the JBoss SAO platform a jbpm deployer would be a nice feature.
The deployer can pick up process archives (par) like other deployers do and deploy these processes to jbpm (hence in the jbpm database).
One additional feature which make sense in my eyes is to also support scoped classloading. In jbpm 3 you can use the configurable ProcessClassLoader to implement the desired behavior.
I sketched the ideas in these two blogging entries, the solution is working at the current project without problems:
In the jbpm team the solution was discussed last week on the meeting, and it was somehow agreed on, that the same behavior should be included in jbpm 4 from the start.
This would be a great addition to the jBPM project, making it a first class resource within the app server. :)
Thanks I'll take a look
Resolved as part of [JBPM-1883] and [JBPM-1884]
Hi Thomas! I am a bit confused about the status now.
What I found in the codebase was a "Deployment" interface and a DeploymenService in "the API".
But how is it included in the ESB? Unfortunately there are no fisheye links to code. And somewhere needs to be a JBoss AS Deployer, right? Is it only targeted for jbpm 4? Then it couldn't go into JBoss ESB 4.3 already, right?
Can you quickly explain? Thanks a lot for sheding light on this...
I do not see SOA-P 5 ER6 configured to support deployment of par files
I don't think this should have been marked as Done in the first place, as no integration of this has ever taken place.
Unassigned myself - could you please discuss this with the jBPM team?
In 2008 we had long dicusions on whether a jbpm deployer was needed or not.
The last I heard was that a deployer was rejected. Instead they preferred to deploy a servlet that installs a process definition directly into the jBPM runtime bypassing the jboss deployer architechture.
As far as I am aware this was discussed at length with the jBPM team and, from the earlier comments on this issue (and JBPM-1883/JBPM-1884), this work should already have been done.
If this is not the case then we need to correct the comments on this case *and* reopen both of those issues.
What appears to be missing is the configuration (and testing of course) of this new deployer within SOA.
afaict, there has not been a promise to the soa platform productization to deliver a jboss deployer for par files. this would have to be discussed at lenght before because it is has a lot of implications. synchronizing pars in a deploy directory with deployments in a jbpm database has a lot of situations that can go bad. writing a jboss deployer that finds and deploys a par file is easy. but how to know at server boot time if a process needs to be redeployed ? how to sync in a cluster? what if the deployment is deleted in jbpm?... etc. all those requirements have to be discussed and agreed before we can go ahead with this.
Yep, I remember having long discussions with you about this :)
Might be a good idea to reopen the JBPM issues in this case, as the work was obviously not done. This does beg the question as to what *was* done though :)
I think this issue is really an interessting one. But I would really like to come to a conclusion, that satisfies the main use cases. First we have to sketch the different lifecycles and an idea how to solve it. I could go ahead with it and propose an idea, I created: JBPM-2743
We do not believe this particular feature is vital for jBPM3 inside of SOA4.3/5.0. It can be looked at again for jBPM4 at some future date.
Process Deployment is currently handled via JBDS/Tools, the console and via ant task.
Deploying via JBDS/Tools is not an option for production environments (if many processes are involved and changes to these also depend on changes in ESB services/other applications), or at least it would be a tedious (and most likely error prone) process.
The ant deployment requires the server to run. There is no way to provision an entire set of changes for instance via Red Hat Satellite (and no way to do a complete software update of a given system without the extra step of deploying the jBPM processes after the system is started as a separate task). jBPM is still a fairly technical tool. Letting business users deploy processes and classes using Eclipse directly without something like BRMS to help with testing etc. is often not realistic.