[ https://issues.jboss.org/browse/AS7-2777?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-2777: --------------------------------------- How is this different from add deploy undeploy remove ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2777?page=com.atlassian.jira.plugin.s... ] Thomas Diesler edited comment on AS7-2777 at 11/28/11 3:02 AM: --------------------------------------------------------------- It is of course a matter of defining the various states and the lifecycle steps between them. Here is what I had in mind * 'deploy' transitions to state INSTALLED - the metadata is valid * a deployment that is INSTALLED can be RESOLVED (i.e. a classloader can get attached). This happens at the discretion of the runtime * 'start' transitions from INSTALLED to RESOLVED (if not happened already) and further to ACTIVE. The deployment's activator is called - the respective services get activated * 'stop' transitions from ACTIVE to RESOLVED. The respective services get deactivated * 'undedploy' transitions to UNINSTALLED - is not available for new wirings. Ready for removal by the runtime You can repeatedly start/stop a deployment without revaluating its metadata, do the unpacking, etc. With the current implementation I believe this is not the case - no DUPs are called for operation 'add' if I'm not mistaken. was (Author: thomas.diesler): It is of course a matter of defining the various states and the lifecycle steps between them. Here is what I had in mind * 'deploy' transitions to state INSTALLED - the metadata is valid * a deployment that is INSTALLED can be RESOLVED (i.e. a classloader can get attached). This happens at the discretion of the runtime * 'start' transitions from INSTALLED to RESOLVED (if not happened already) and further to ACTIVE. The deployment's activator is called - the respective services get activated * 'stop' transitions from ACTIVE to RESOLVED. The respective services get deactivated * 'undedploy' transitions to UNINSTALLED - is not available for new wirings. Ready for removal by the runtime -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2777?page=com.atlassian.jira.plugin.s... ] Thomas Diesler reassigned AS7-2777: ----------------------------------- Assignee: Thomas Diesler -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2777?page=com.atlassian.jira.plugin.s... ] Jason Greene commented on AS7-2777: ----------------------------------- I think the mapping for what we have today should be: deploy = add start = deploy stop = undeploy undeploy = remove. As to the OSGi case, we have that long standing deployment chain refactor (pushed outside of 7.1) that would better handle the INSTALLED/RESOLVED case. That scenario would involve having the OSGi deployment chains stop mid way through and lazily start based on an external demand (osgi decides to move to installed). We could, at that time decide to map start in 88 to mean force a full start (assuming that's helpful) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2777?page=com.atlassian.jira.plugin.s... ] Rob Stryker commented on AS7-2777: ---------------------------------- I do know a user on the JBossTools forums once was strongly demanding the ability to 'stop' a deployment without undeploying it. We tried repeatedly to explain there was no way to do it. A 'stop' was functionally equivilent to 'undeploy', but he refused to believe it... What he was requesting was basically exactly this jira. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2777?page=com.atlassian.jira.plugin.s... ] Thomas Diesler commented on AS7-2777: ------------------------------------- Status update: I added deployment operations start/stop and the ability in the DeploymentPlanBuilder to say {code} andDeploy().andNoStart() {code} Following the INSTALL phase there is a new ACTIVATE phase. When the 'deploy' operation is marked with StartPolicy.DEFERRED the DeploymentPhaseService for ACTIVATE is created with initial Mode.NEVER, which causes no execution of DUPs in ACTIVATE and beyond. The 'start' operation, triggers continuation of DUP execution by setting the DeploymentPhaseService for ACTIVATE to Mode.ACTIVE. The 'stop' operation sets the DeploymentPhaseService for ACTIVATE to Mode.NEVER In this way start/stop can be called repeatedly Test coverage in {code} [tdiesler@tdvaio smoke]$ mvn -Dtest=StandaloneDeploymentTestCase install Running org.jboss.as.test.smoke.osgi.StandaloneDeploymentTestCase Tests run: 12, Failures: 0, Errors: 0, Skipped: 3, Time elapsed: 20.721 sec {code} https://github.com/tdiesler/jboss-as/tree/as2777 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2777?page=com.atlassian.jira.plugin.s... ] Thomas Diesler updated AS7-2777: -------------------------------- Component/s: Deployment Layer (was: Domain Management) (was: Server) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2777?page=com.atlassian.jira.plugin.s... ] Thomas Diesler updated AS7-2777: -------------------------------- Priority: Major (was: Minor) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2777?page=com.atlassian.jira.plugin.s... ] Thomas Diesler commented on AS7-2777: ------------------------------------- I rebased this on top of the current AS7-3694 approach -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira