[jboss-as7-dev] Allign deployment phases with OSGi terminology

Thomas Diesler thomas.diesler at jboss.com
Thu Jul 26 16:26:22 EDT 2012


One of the original motivations to align the deployment phases with the 
OSGi terminology

INSTALL:  valid metadata, installed with the framework - access to 
resources no classloader
RESOLVE:  find consistent wiring associate classloader
ACTIVATE: register services, put the deployment to work

is that Phase.INSTALL is confusing with the OSGi meaning of INSTALL. I 
always have to use many words when I talk about 'install' in AS7. Now 
that we support war,ejb3,cdi deployments as OSGi bundles this is even 
more so.

 > Phases are named in terms of what is available when the phase is complete

This may be true for javaee deployments. An OSGi deployment may not get 
a Module associated in Phase.MODULE. We continuously fix issues in DUPs 
that assume an attached Module in the phases past CONFIGURE_MODULE. As 
you know, the idea of always associating a Module during deployment 
creates an ordering issue. If moduleA depends on moduleB - you must 
deploy B before A. This is of course unmanageable for a complex graph of 
dependencies.

Therefore, OSGi deployments may just get installed (no resolution, no 
ordering). An external trigger may later resolve the bundles and cause 
their Module association.

I don't think its a big deal to rename these phases (no functional 
change). Going forward we could share the same language when talking 
about deployments and their respective states. For example when you put 
OSGi metadata in your WAR it becomes an OSGi Web Application Bundle 
(WAB). It can take advantage of the Bundle lifecycle (start/stop the 
http endpoint), use standard modularity based on caps/reqs, use OSGi 
services to provide functional dynamicity.

When you say a WAB gets INSTALLED, it is very different to a WAR going 
through Phase.INSTALL. An installed WAB does not have a classloader 
associated let alone its http endpoint being accessible.

Please reconsider, it makes explaining what's going on during these 
phases much clearer IMHO

cheers
-thomas

On 07/26/2012 04:25 PM, David M. Lloyd wrote:
> On 07/26/2012 09:04 AM, Thomas Diesler wrote:
>> Folks,
>>
>> this is related to AS7-3585 <https://issues.jboss.org/browse/AS7-3585>
>>
>> I propose the following mapping
>>
>> 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
>>
>> In a first commit I would simple rename the phases and associated
>> constants but not the DUPs that have the phase in their class name.
>> This would also address the need for a new phase (POST_ACTIVATE) that is
>> needed for OSGi webapp integration.
>>
>> Thoughts?
> Not for 7.x.  And I'm not 100% sure 8.x will work 100% the same way.
> Even if it did I don't think there's a great benefit to aligning to the
> OSGi way - it makes the other 90% make a lot less sense.  Phases are
> named in terms of what is available when the phase is complete.  As it
> is, we should not have added a new phase; I still see that as a mistake.
>    You can achieve the same effect by interposing services during the
> regular deployment lifecycle.
>
> Instead OSGi should probably have a parallel service chain that uses
> dependencies on the primary chain in order to sync up with normal
> deployments.
>

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx



More information about the jboss-as7-dev mailing list