lifecycle stages ramblings

[Stephen McConnell <mc...@apache.org>]

Following from Berin's recent post on the subject of lifecycle 
extensions - I though it would be a good idea to present some thoughts 
and experience I've had in terms of thinking, dealing with, and 
implementing abstract lifecycle stages and a proposal to enhance what we 
already have.

First of all, there are two separate and distinct deployment phases that 
we are concerned about:

  * component type deployment
  * component instance deployment

When we create a new class instance (e.g. m_classloader.loadClass( 
"Whatever" ) ) - the JRE is providing class deployment beyond the 
scenes.  This includes things like locating the class bytecode, building 
the class definition, and validating the class before returning the 
class to the client.  I figure we are all aware of the 
ClassNotFoundException which is simply declaring failure of class 
deployment due to a missing definition.  The less well known exception 
NoClassDefFoundError is thrown when you attempt to load a class that has 
a dependency on another class and the dependent class is not found. The 
are bunch of other errors that can occur - the point is that the 
construction of a valid class is a process of class deployment.

When we combine a class with component meta-info we need to also think 
about the implications this has on component type deployment.  For 
example, a component type may declare lifecycle stage dependencies, 
context management dependencies, context entry dependencies, and service 
dependencies. As far as component type deployment is concerned - a 
container could go through the process of pre-assembly of the classes 
needed to handle all of these dependencies - validating that classes are 
accessible, validating semantics such as class assignment to an 
interface class and so on.  On completion of component type deployment 
we know that instance level deployment is possible.

Object deployment is handled inside the JVM (e.g. MyClass.newInstance() 
) A container supplements instance creation with lifecycle stage 
processing.   Lifestyle management concerns the application of a series 
of ordered lifecycle stages to a component. These stages and their 
ordering are defined by the framework contracts. From the point of view 
of a container implementation - two of these stages (initialization and 
disposal) were semantically extended through the introduction of the 
concept of lifecycle extensions.  While lifecycle extension 
implementation is largely linked to the excalibur-lifecycle package, the 
notion of stage is more abstract.  As Aaron pointed out not so long ago 
- there are usage cases for lifecycle stages that do not necessarily 
interact with the component under deployment.  There are other lifecycle 
stage use-cases which are independent of excalibur-lifecycle in use 
today in Merlin as part of overall approach to non-Avalon component 
management (i.e. stage extension unrelated to initialization and disposal).

To fully understand the lifecycle stages and relationship between tags, 
tools, meta-info, containers and components, we need to consider what 
abstract is being address at the resolve level:

|------------------------------------------------------|
| @avalon.stage   | Declares that a component type     |
|                 | has a deployment dependency on     |
|                 | a lifecycle stage.                 |
|-----------------|------------------------------------|
| tool            | A container specific tool can      |
|                 | perform static validation relative |
|                 | to the containers stage management |
|                 | strategy.                          |
|                 |                                    |
|                 | Existing tools simply provide for  |
|                 | the generation of <stage> element  |
|                 | with a meta-info descriptor (or    |
|                 | serialized object) that declares   |
|                 | abstract stage dependency.         |
|-----------------|------------------------------------|
| container       | As part of type deployment a       |
|                 | a container can apply default or   |
|                 | or container specific logic to the |
|                 | resolution of a mechanism through  |
|                 | a stage dependency is resolved.    |
|                 | Currently the stage dependency is  |
|                 | urn and a set of attributes.  The  |
|                 | urn identifies an extension        |
|                 | descriptor.  Mapping of an         |
|                 | extension implementation is a      |
|                 | container concern.                 |
|-----------------|------------------------------------|
| component       | A component is passive participant |
|                 | in that is may or may not share    |
|                 | any interaction with a lifecycle   |
|                 | stage. Normally, a component       |
|                 | implementation will implement some |
|                 | interface through which an         |
|                 | extension will interact.           |
|------------------------------------------------------|

 From this context, there are some improvements that I would like to see 
to the excalibur-extension package.  These improvements are totally 
independent of the tag model or meta-model.

The excalibur-lifecycle extension package is our first cut and dealing 
with one small aspect of dealing with lifecycle stage customization.  
Through experience a number of things have been learnt.  Firstly, the 
existing interface Create actually handles two phases - component 
deployment and decommissioning.  These two separate concerns should be 
broken out into separate interfaces.  Secondly, the operations defined 
in the interface imply that a component must be contextualizable.  This 
creates an unnecessary overhead on a container. A short-term solution is 
to add operations that do not take a context object as an argument.  In 
the longer term, the solution IMHO is to supply a meta model instance 
such that an extension is simply an abstract extension point (but that's 
a while away so perhaps my short-term comment is premature).

Evolution of excalibur extension that I would like to see introduced:

1. redefine Creator to aggregate two new interface:

   public interface Creator extends
     DeploymentExtension, DecommissionExtension{}

2. define DeploymentExtension such that is consistent with the existing 
Create interface and supplement it with non-context and non-object 
related operations.

   public interface DeploymentExtension
   {
       void create(); // new
       void create( Object object ); // new
       void create( Object object, Context context ); // compatible
   }

3. do the same thing with DecommissionExtension

   public interface DecommissionExtension
   {
       void destroy(); // new
       void destroy( Object object ); // new
       void destroy( Object object, Context context ); // compatible
   }

To conclude - what I have tried to describe here is the separate levels 
of abstract that exist with respect to lifecycle stage management - from 
abstract dependency declarations via the @avalon.stage tag, propagation 
of that abstract dependency via tools to a meta-info model, solution 
management within a container, and lastly, suggestions for improvement 
and optimization of the default implementation strategy.

Cheers, Steve.

----------------------

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org