[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