[Design of JBoss jBPM] - Re: Rework of jBPM deployment within JBoss
by tom.baeyens@jboss.com
"bill.burke(a)jboss.com" wrote :
| Its as simple as configuring Hibernate to "update" mode so that the schema is created on boot time.
|
| As for JCA, an outbound adapter for jbpm might be interesting so that you could inject JBPM contexts and would give you somewhat of a portable way of doing deployment. Like, with the outbound configuration, you'd specify the .jpdl file or process archive to load.
|
I'm not sure if we're on the same page here. I discussed with weston that it would be possible to use JCA/RAR for the following:
upon server boot,
1) update the schema using hibernate's tool
2) produce a JbpmConfiguration in JNDI
"bill.burke(a)jboss.com" wrote :
| anonymous wrote :
| | saving that info in the database is going to be tricky in 3.2.x as we only want to allow updates to the db schema between minor version releases. 3.3 is still some time out.
| |
|
| Why so tricky? Just create another table.
| create table(
| process_name VARCHAR,
| process_version int,
| process_hash long
| );
|
Managing and documenting all of this. Managing the right hibernate mappings to be used in deployment. People deploy jBPM in *many* different ways. My current strategy is to try and limit the ways it is being deployed. Creating an extra table is not hard to get working, but many users will be confronted with either a table that doesn't exist and that should exist or similar problems with the hibernate mappings.
i think it should be possible to reuse an existing field for it in 3.2.x or just wait till 3.3 comes out. Then we can introduce a new table.
anonymous wrote : A RAR would be limited and you would still need to deploy 2 separate files, a pd-ds.xml file, to define the process instance, and the .par file (or .jpdl file). Where in a JBoss deployer, its just one file and less metadata to write.
|
i agree with building a jboss deployer based on hash codes.
i'm only trying to separate the parts that you put into the depoyer into 2 separate modules:
1) automatic database update and putting the JbpmConfiguration in JNDI (that can be done in a portable RAR deployment, afaik)
2) jboss process deployer
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052183#4052183
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052183
18 years, 10 months
[Design of JBoss jBPM] - Re: Rework of jBPM deployment within JBoss
by tom.baeyens@jboss.com
"david.lloyd(a)jboss.com" wrote : "kukeltje" wrote : I agree, that he/she should have the option, but that should also be the case for changes in the .xml file. (small typo's in some text e.g.) and what about the forms....
| |
|
| Exactly. That's why I said to hash the semantic graph structure, rather than the file itself. The only change that absolutely requires a deployment of a new version is a change in the graph structure. For any other change, it should be controllable by the user whether a new version is deployed.
i don't think it's good to have a model that has a complicated calculation on wether or not it will redeploy.
in development it doesn't matter if you redeploy too much.
in production you won't update the file that often.
so i don't really see a problem with just using a hashcode of the total process archive, preferrably in combination with the timestamp of the file. without inspecting the contents of the deployed process
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052172#4052172
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052172
18 years, 10 months