[jboss-jira] [JBoss JIRA] Closed: (BPEL-280) redeploy web modules upon server restart

redeploy web modules upon server restart ---------------------------------------- Key: BPEL-280 URL: http://jira.jboss.com/jira/browse/BPEL-280 Project: JBoss jBPM BPEL Issue Type: Task Security Level: Public(Everyone can see) Components: Engine Reporter: Alejandro Guizar Assigned To: Alejandro Guizar Fix For: jBPM BPEL 1.1 GA PROBLEM With the automated deployment procedure in place, new processes and the associated web services can be deployed on the fly. There is an issue, however. Upon server restart, web modules deployed through the JBoss AS main deployer dissapear. Three approaches come quickly to mind to address this situation: PROPOSAL 1. Place the modules directly in the deployment directory of the application server * Pros. The engine needs not perform any task at startup. The server is responsible for reading and deploying the modules. * Cons. Loss of portability. Servers other than JBoss AS use different deployment directories. Some may not even support the concept of a deployment directory. Furthermore, what if the modules are deleted? Because the responsibility is trasferred to the server, there can be a disconnection between the process definitions in the jBPM database and the deployed web services. PROPOSAL 2. Save the prefabricated deployment artifacts in the process definition. Rebuild the module at startup. * Pros. No external location is required to place the modules. All information required to rebuild them is saved along the process definition. The disconnection between the process definitions and the deployed web services dissapear. * Cons. The engine has to process each process definition at startup to rebuild the modules. This could result in a significant startup time. Plus, database space consumption might become excessive. PROPOSAL 3. Save the prefabricated module in a content repository. Leverage the repository facilities provided by jBPM. * Pros. Same as 2. Plus, no large database storage requirements. * Cons. The engine still has to process each process definition at startup. Plus, an external content repository introduces new dependencies and installation complexities to the product. Among these proposals, #1 looks good because it neither imposes large database storage requirements nor a significant startup processing time. It is also the easiest to implement, at the expense of brittleness due to the reliance on the app server. Any comments or new proposals welcome.