Re: [jboss-as7-dev] Update to deferred resolve and start/stop

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 >> >