Heiko wrote :
| 1) a changed pdl file, but classes remain the same
| 2) same pdl, but classes changed
| 3) changed pdl and classes changed
|
| IMO 1) and 3) should lead to a new version of that process, i.e. demanding an explicit
version increment in the pdl, whereas 2) simply associated a different resource set to
with process (i think bernd called it patching/bug fixes)
|
I see the use cases a bit different:
1) Fix a process (patching/bug fixing)
a) with changed classes
b) with changed jpdl
c) or both
2) Deploy a rael new version
with changed classes
and with changed jpdl
The distinction between fix and new version cannot be based dependent on the changed
artefacts but has to be made from the user.
1a is simply a redeployment on the server
1b creates a new process version of same process in database
2 creates a new process in database and adds the deployment classes.
I would like to keep process db versioning for use case 1b. If you think of long running
processes being forced to release a new version (with classes and stuff as a new
deployment artefact) just because one state was forgotten seems unhandy for me. And then
you have to develop sophisticated mechanisms to undeploy not longer used processes. With
the db versioning it just "fades out".
But maybe I am too used to the current process versioning concept already and like it too
much ;-) At least I can say, that it is good for marketing to support it ;-)
@Tom: Classloading work pretty well if you correctly use scoped classloading of AS with
different parallel versions if the deployer and service take care of it correctly. The
deployer I wrote for jbpm 3 works productive at the customer without problems...
For the execution modes: Yeah, differentiate these and support each of them would be quite
interesting!
Even if I would prefer "persistent dynamic" for most use cases, because then
you have all information together in the database (good for reporting or BI as well, or?
In fact BI/ETL tools normally talk to databases not to XML files in the classpath ;-)).
But on the other hand persistent process resource could be really an interesting choice
for some scenarios, I have to think more about and play with it a bit... What scares me is
to loose the foreign keys to the process definition. And I could imagine implementing all
the nuts and bolts of it isn't quite easy. And the question is: where is the big
advantage of it? But during writing, I start to like it more and more ;-)
The idea about the embedded execution modes are really very interesting, since you find
these kind of customer tables quite often and it could provide a good migration strategy
towards jbpm :-)
Cheers
Bernd
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210940#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...