"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' ? 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. "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 ? "bill.burke(a)jboss.com" wrote : | b) You need to modify your ant build to save your .jpdl into the database so that the jBPM server can pick things up. OR you do some other manual or programmatic process to get your process definitions in the database. | 3 ways of deployment of which you mentioned already 2 * ant task * API * file upload in the web console "bill.burke(a)jboss.com" wrote : | c) You need to copy and .jar files into the JBoss lib/ directory, WAR archive, or whatever. | i don't get what you are referring to here "bill.burke(a)jboss.com" wrote : | I want to create a ProcessDefinitionDeployer for jboss. This will work like the SAR, EJB, EAR, etc... deployers. Users would be able to deploy a .jar file named "xxx.bpm" or a foo.jpdl.xml file. The jar file would contain a "META-INF/jbpm.jpdl.xml" file within it and any classes that could possibily be used by the process definition. | process definition deployer: yes META-INF/jbpm.jpdl.xml: we already have a process archive format called process archive. though, we should rename it from .par to .process or something like that to prevent conflicts with the persistence archives. "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. 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. but it can be done in 3.2.x with a file attachment (see processDefinition.getFileDefinition()) but the query to see if a process is already deployed is going to be based on a binary column... not sure if that is db portable. on the other hand, it will be a pain to manage separate tables for the jboss deployer i think. if we have lots of processes (avg would be 10-20 i guess with lots being more then 1000), what will this do to the startup time of jboss ? "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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051985#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...