Folks, I rebased the as2777 <https://github.com/tdiesler/jboss-as/tree/as2777> branch on the current as3694 <https://github.com/tdiesler/jboss-as/tree/as3694> approach. This integrates with the CLI and you can do <deployment name="simple.war" runtime-name="simple.war"> <content sha1="be6f7ba1ceaa2028c86d080648e1467904999f8e"/> <properties> <property name="start.policy" value="deferred"/> </properties> </deployment> [tdiesler@tdvaio jboss-as-7.2.0.Alpha1-SNAPSHOT]$ bin/jboss-cli.sh --connect [standalone@localhost:9999 /] start simple.war [standalone@localhost:9999 /] stop simple.war on the server you should see 08:56:30,002 INFO [org.jboss.web] (MSC service thread 1-2) JBAS018210: Register web context: /simple 08:57:16,533 INFO [org.jboss.web] (MSC service thread 1-3) JBAS018224: Unregister web context: /simple The current implementation sets the initial mode of the CONFIGURE_MODULE to NEVER for start.policy=deferred The start/stop operations toggle the mode of the INSTALL phase service between ACTIVE/NEVER. The CLEANUP phase is currently a problem on repeated start. You'll see Caused by: java.lang.NullPointerException atorg.jboss.as.ejb3.deployment.processors.merging.AbstractMergingProcessor.deploy(AbstractMergingProcessor.java:61) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:124) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2 because the EEModuleDescription is no longer attached. Stopping a deployment would not need to take the Module and associated ClassLoader down. So any datastructures needed to configure the Module can safely be cleaned up IMHO. I presume the DUPs can reasonably be fixed by moving them to the appropriate phases (see below) and by making

sure they still have the data structures attached to do yo-yo on the activate phases. Using this terminology <https://issues.jboss.org/browse/AS7-3585> STRUCTURE => STRUCTURE PARSE => PRE_INSTALL REGISTER => INSTALL => POST_INSTALL DEPENDENCIES => PRE_RESOLVE CONFIGURE_MODULE => RESOLVE FIRST_MODULE_USE => POST_RESOLVE POST_MODULE => PRE_ACTIVATE INSTALL => ACTIVATE => POST_ACTIVATE CLEANUP => CLEANUP We could stop at PRE_RESOLVE. Subsequent start would go up to and including CLEANUP. Subsequent stop would go back including PRE_ACTIVATE. Subsequent start as before. cheers --thomas -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler JBoss OSGi Lead JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On 09/20/2012 02:29 PM, Scott Marlow wrote: > On 09/20/2012 09:18 AM, Thomas Diesler wrote: >> Folks, >> >> I rebased the as2777 <https://github.com/tdiesler/jboss-as/tree/as2777> >> branch on the current as3694 >> <https://github.com/tdiesler/jboss-as/tree/as3694> approach. >> >> This integrates with the CLI and you can do >> >> <deployment name="simple.war" runtime-name="simple.war"> >> <content sha1="be6f7ba1ceaa2028c86d080648e1467904999f8e"/> >> <properties> >> <property name="start.policy" value="deferred"/> >> </properties> >> </deployment> >> >> [tdiesler@tdvaio jboss-as-7.2.0.Alpha1-SNAPSHOT]$ bin/jboss-cli.sh >> --connect >> [standalone@localhost:9999 /] start simple.war >> [standalone@localhost:9999 /] stop simple.war >> >> on the server you should see >> >> 08:56:30,002 INFO [org.jboss.web] (MSC service thread 1-2) JBAS018210: >> Register web context: /simple >> 08:57:16,533 INFO [org.jboss.web] (MSC service thread 1-3) JBAS018224: >> Unregister web context: /simple >> >> The current implementation sets the initial mode of the CONFIGURE_MODULE >> to NEVER for start.policy=deferred >> The start/stop operations toggle the mode of the INSTALL phase service >> between ACTIVE/NEVER. >> >> The CLEANUP phase is currently a problem on repeated start. You'll see >> >> Caused by: java.lang.NullPointerException >> atorg.jboss.as.ejb3.deployment.processors.merging.AbstractMergingProcessor.deploy(AbstractMergingProcessor.java:61) >> >> at >> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:124) >> >> [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2 >> >> because the EEModuleDescription is no longer attached. >> >> Stopping a deployment would not need to take the Module and associated >> ClassLoader down. So any datastructures needed to configure the Module >> can safely be cleaned up IMHO. I presume the DUPs can reasonably be >> fixed by moving them to the appropriate phases (see below) and by making > > Which DUPs do you propose moving and to which phase? Currently, the > first DUP to use a deployment module classloader, is JPA (for class > enhancing (rewriting) in the FIRST_MODULE_USE phase as part of > creating the EntityManagerFactory). If class enhancing is not > enabled, the JPA entity manager factory is created during the INSTALL > phase. All DUPs currently assume that they run in a single transaction. IOW, the DUPs in the INSTALL phase are not designed for the deployment to yo-yo in that phase, which they would have to do if we are going to implement deployment start/stop behaviour (without reconstruction on the Module) properly. I suggest the review the DUPs in the INSTALL phase to see whether they use data structures that are removed in the CLEANUP phase. There are two possibilities #1 DUP (in INSTALL) should be moved to a phase that is only executed once. Then the associated data can safely be discarded in CLEANUP #2 DUP (in INSTALL) should only use data that stays attached with the DU and is not discarded in CLEANUP I guess this has to be decided on a case-by-case basis. Each subsystem would have to make up its mind what it means to start/stop their respective deployments. For a webapp that probably means to start/stop the web context.

> >> sure they still have the data structures attached to do yo-yo on the >> activate phases. >> >> Using this terminology <https://issues.jboss.org/browse/AS7-3585> >> >> STRUCTURE => STRUCTURE >> >> PARSE => PRE_INSTALL >> REGISTER => INSTALL >> => POST_INSTALL >> >> DEPENDENCIES => PRE_RESOLVE >> CONFIGURE_MODULE => RESOLVE >> FIRST_MODULE_USE => POST_RESOLVE >> >> POST_MODULE => PRE_ACTIVATE >> INSTALL => ACTIVATE >> => POST_ACTIVATE >> >> CLEANUP => CLEANUP >> >> We could stop at PRE_RESOLVE. Subsequent start would go up to and >> including CLEANUP. Subsequent stop would go back including PRE_ACTIVATE. >> Subsequent start as before. >> >> cheers >> --thomas >> >> >> -- >> xxxxxxxxxxxxxxxxxxxxxxxxxxxx >> Thomas Diesler >> JBoss OSGi Lead >> JBoss, a division of Red Hat >> xxxxxxxxxxxxxxxxxxxxxxxxxxxx >> >> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >

deploy foo.jar --no-start (which means it is ok that foo cannot resolve) deploy bar.jar start foo.jar (which means that foo must resolve and start without error) stop foo.jar (which means that foo runs back through the activate

I did no a similar thing a little while ago, that would allow a deployment with a dependency on another deployment to basically sit and wait for the next deployment to come up. I think the way to implement this is to have the configure CONFIGURE_MODULE phase be set to passive, so it only starts when the services that it depends on become available. So in the OSGI case this would depended on the RESOLVE services, and would start as soon as resolution completed. Things get more complicated if this passive service has its dependencies go away, as deployment phases are not restartable. I think the only way to actually handle this is to perform a full re-deployment. The reason why this is so problematic is because the DUP contains a lot of mutable state that is modified in each phase. Re-running all the DUP's would result in a lot of this information being doubled up. It is also more complicated if we are dealing with a multi-module deployment. If any of the sub deployments are not set to start lazily, and are dependent on services that are present in the lazy deployment then this will fail. This will probably not be a big deal in practice. Another big issue is that we have no way of reporting the success or failure of the deployment back to the user. We also need to make sure that if this passive deployment fails we have some way of rolling back the deployment, to keep the behavior consistent with normal deployments. We do not want to leave a half finished deployment sitting around. Basically I think this is possible for a fairly limited case where: - The deployment stops after configure module - We have a mechanism in place to prevent the DU from attempting to restart without a full re-deployment. - We make sure that partial deployment is not allowed, and a full rollback is attempted if start fails. Stuart Scott Marlow wrote: > On 09/20/2012 02:52 PM, Thomas Diesler wrote: >> On 09/20/2012 02:29 PM, Scott Marlow wrote: >>> On 09/20/2012 09:18 AM, Thomas Diesler wrote: >>>> Folks, >>>> >>>> I rebased the >>>> as2777<https://github.com/tdiesler/jboss-as/tree/as2777> >>>> branch on the current as3694 >>>> <https://github.com/tdiesler/jboss-as/tree/as3694> approach. >>>> >>>> This integrates with the CLI and you can do >>>> >>>> <deployment name="simple.war" runtime-name="simple.war"> >>>> <content >>>> sha1="be6f7ba1ceaa2028c86d080648e1467904999f8e"/> >>>> <properties> >>>> <property name="start.policy" value="deferred"/> >>>> </properties> >>>> </deployment> >>>> >>>> [tdiesler@tdvaio jboss-as-7.2.0.Alpha1-SNAPSHOT]$ bin/jboss-cli.sh >>>> --connect >>>> [standalone@localhost:9999 /] start simple.war >>>> [standalone@localhost:9999 /] stop simple.war >>>> >>>> on the server you should see >>>> >>>> 08:56:30,002 INFO [org.jboss.web] (MSC service thread 1-2) >>>> JBAS018210: >>>> Register web context: /simple >>>> 08:57:16,533 INFO [org.jboss.web] (MSC service thread 1-3) >>>> JBAS018224: >>>> Unregister web context: /simple >>>> >>>> The current implementation sets the initial mode of the >>>> CONFIGURE_MODULE >>>> to NEVER for start.policy=deferred >>>> The start/stop operations toggle the mode of the INSTALL phase >>>> service >>>> between ACTIVE/NEVER. >>>> >>>> The CLEANUP phase is currently a problem on repeated start. You'll >>>> see >>>> >>>> Caused by: java.lang.NullPointerException >>>> atorg.jboss.as.ejb3.deployment.processors.merging.AbstractMergingProcessor.deploy(AbstractMergingProcessor.java:61) >>>> >>>> >>>> at >>>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:124) >>>> >>>> >>>> [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2 >>>> >>>> because the EEModuleDescription is no longer attached. >>>> >>>> Stopping a deployment would not need to take the Module and >>>> associated >>>> ClassLoader down. So any datastructures needed to configure the >>>> Module >>>> can safely be cleaned up IMHO. I presume the DUPs can reasonably be >>>> fixed by moving them to the appropriate phases (see below) and by >>>> making >>> Which DUPs do you propose moving and to which phase? Currently, the >>> first DUP to use a deployment module classloader, is JPA (for class >>> enhancing (rewriting) in the FIRST_MODULE_USE phase as part of >>> creating the EntityManagerFactory). If class enhancing is not >>> enabled, the JPA entity manager factory is created during the INSTALL >>> phase. >> All DUPs currently assume that they run in a single transaction. IOW, >> the DUPs in the INSTALL phase are not designed for the deployment to >> yo-yo in that phase, which they would have to do if we are going to >> implement deployment start/stop behaviour (without reconstruction on >> the >> Module) properly. >> >> I suggest the review the DUPs in the INSTALL phase to see whether they >> use data structures that are removed in the CLEANUP phase. There are >> two >> possibilities >> >> #1 DUP (in INSTALL) should be moved to a phase that is only executed >> once. Then the associated data can safely be discarded in CLEANUP >> >> #2 DUP (in INSTALL) should only use data that stays attached with >> the DU >> and is not discarded in CLEANUP >> >> I guess this has to be decided on a case-by-case basis. Each subsystem >> would have to make up its mind what it means to start/stop their >> respective deployments. For a webapp that probably means to start/stop >> the web context. > > JPA class enhancing/rewriting (if enabled), needs to happen before any > application classes are loaded. The JPA class enhancing/rewriting > occurs when the EntityManagerFactory is created. > > If we were to allow non-JPA deployers to run in the same or earlier > phase as JPA, we would need a strong guard to prevent the non-JPA > deployers from invoking any code that could load application classes > (while letting JPA to load application classes). > >>>> sure they still have the data structures attached to do yo-yo on the >>>> activate phases. >>>> >>>> Using this terminology<https://issues.jboss.org/browse/AS7-3585> >>>> >>>> STRUCTURE => STRUCTURE >>>> >>>> PARSE => PRE_INSTALL >>>> REGISTER => INSTALL >>>> => POST_INSTALL >>>> >>>> DEPENDENCIES => PRE_RESOLVE >>>> CONFIGURE_MODULE => RESOLVE >>>> FIRST_MODULE_USE => POST_RESOLVE >>>> >>>> POST_MODULE => PRE_ACTIVATE >>>> INSTALL => ACTIVATE >>>> => POST_ACTIVATE >>>> >>>> CLEANUP => CLEANUP >>>> >>>> We could stop at PRE_RESOLVE. Subsequent start would go up to and >>>> including CLEANUP. Subsequent stop would go back including >>>> PRE_ACTIVATE. >>>> Subsequent start as before. >>>> >>>> cheers >>>> --thomas >>>> >>>> >>>> -- >>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx >>>> Thomas Diesler >>>> JBoss OSGi Lead >>>> JBoss, a division of Red Hat >>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx >>>> >>>> >>>> >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev