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

[Scott Marlow]

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 at tdvaio jboss-as-7.2.0.Alpha1-SNAPSHOT]$ bin/jboss-cli.sh
>>> --connect
>>> [standalone at localhost:9999 /] start simple.war
>>> [standalone at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>
>