[jboss-dev-forums] [Design of JBoss jBPM] - Re: Rework of jBPM deployment within JBoss

"tom.baeyens(a)jboss.com" wrote : "bill.burke(a)jboss.com" wrote : | | 1. The hibernate and jbpm xml files are embedded deep within the enterprise archive. These need to be moved up for easy edits by the user | | | | one option could be to extract all the .hbm.xml files and put then in the config jar file. would that qualify as 'moved up' ? | Has to be an exploded archive so people don't have to unjar things. The less people have to do, the better. anonymous wrote : | i definitely want at least something that is as portable as this solution. if there are jboss specific ways on how to move the configs even up further, i 'm ok with that as long as it's another option that we offer apart from the portable deployment. | It would be another option, as its definately JBoss specific. anonymous wrote : | "bill.burke(a)jboss.com" wrote : | | a) You need to create the jBPM schema in the database | | | | Previously detection and update of the schema was done automatically in a .sar. But i want to move to a portable .rar for this. Would that be an option for you ? | 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. anonymous wrote : | "bill.burke(a)jboss.com" wrote : | | At deployment time, the JBPM deployer would calculate a hash for hte .xml file. If this hash matches a previously deployed .xml file nothing is done. If it is a new hash, a new version of the process definition is saved to the database. | | | | hash in combination with the last update time of the file would be good, i think. i wouldn't trust hash only. chances are small for a collision, but imagine if you have such a collision, then you would have to make sure something in the file is changed to get it deployed. | I can't imagine having such a collision as you have a higher chance of getting struck by lightning. RMI and our EJB code uses an MD5 of a method to send its identity over the wire. 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 ); Its something only the deployer knows about. 1. Parse the .jpdl file. 2. Create an MD5 hash of the file (or object model or whatever) 3. Get PD name from deployed file 4. query table for latest PD 5. compare hashes 6. If new, insert into table name, version++, new_hash 7. create new PD in JBPM anonymous wrote : | "bill.burke(a)jboss.com" wrote : | | A new config structure would look like this: | | | | | | | jbpm.deployer/ | | | hibernate.cfg.xml | | | jbpm.cfg.xml | | | jbpm-ds.xml | | | jbpm-jpdl.jar | | | jbpm-enterprise.ear | | | META-INF/ | | | jboss-service.xml | | | | | that looks good. but consider JCA and a .rar to deploy jbpm separate on the appserver, apart from the deployer. then the .rar would be portable. 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. What's also good about the JBoss model is you would be able to compose applications into one archive: | foo.sar/ | ejbs.jar | jbpm-app.par | foo-dsl.xml | with JBoss 5 it would be even more interesting and simple as a multiple deployers can process one archive (unlike JBoss 4). | jbpm-app.jar/ | com/ | org/ (class files, could be annotated components like EJB and SEAM) | foo-ds.xml | META-INF/ | ejb-jar.xml | jbpm.jpdl.xml | seam-components.xml | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052110#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...