You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2002/08/13 18:45:54 UTC

lifecycle extension proposal

Currently we have two different lifecycle extension interface (Fortress 
style and Merlin style). This email processes a common single approach.  
The current interfaces in Merlin and Fortress are detailed below 
together with a summary of the differences and the issue I have with 
both approaches.  I've summarized the objectives relative to a common 
model, and detailed a two interfaces that could be used as a common 
solution for both Merlin and Fortress.  I have also included an example 
of the extension related meta-info that would be required.

Current Fortress extension interface:
-------------------------------------

     public interface LifecycleExtension
     {
         void create( Object object, Context context );
         void destroy( Object object, Context context );
         void access( Object object, Context context );
         void release( Object object, Context context );
     }

Current Merlin extension interface
---------------------------------

     public interface Extension
     {
         void extend( int stage, Object object, Context context )
            throws Exception;
     }

Differences
-----------

In the Merlin model an extension implementation declares the stages it 
supports (create, destroy, access and release) and the Merlin framework 
only calls the extension for those stages.  In Fortress the stage is 
called irrespective of the extension's requirement to handle the stage.  
Another difference is the declaration of "throws Exception" that is 
included in the Merlin case but not in the Fortress case.

Issues
------

In both solutions there is a context argument supplied for every stage.  
In Fortress a general context object is passed in by the container.  In 
Merlin the context object is built based on the implementations 
declaration of the context information it needs.  In both cases this 
seems problematic. In the Fortress case its not clear what the context 
contains and what context values an extension implementation can depend 
on.  In Merlin its possible to declare the context constraints and 
establishment criteria in the x-files, however, the supply of context 
under the destroy, access and release stages seems questionable - I 
believe we should only be supplying context during the create stage.  An 
implementation is free to hold a reference to the supplied context if it 
needs this information in subsequent stages.

Another issue raises was the simplicity factory.  The Fortress model is 
generally considered to be easier to understand (due to explicit methods 
for each stage as opposed to the enumeration approach in Merlin).

Objective
---------

Establish a common interface or set of interfaces that are shared by 
Merlin and Fortress for extension management, meeting the following 
criteria:

  1. readily understandable method signatures
  2. separation of individual stages (i.e. an extension does not
     need to support all stages)
  3. type validation - ability to inspect an handler implementation
     to see if it implements a lifecycle stage and ability to inspect
     the target component to see if it implements the extension stage
     interface
  4. context validation - ability to know what context information a
     stage requires prior to lifecycle stage invocation
  5. exception support - provide ability for an extension to throw an
     exception in creation and access stages

Interface Proposal
------------------

The following two interfaces are proposed as a common replacement of the 
Merlin Extension interface and Fortress LifecycleExtension interface.

    interface Creator
    {
         void create( Object object, Context context ) throws Exception;
         void destroy( Object );
    }

    interface Accessor
    {
         void access( Object object ) throws Exception;
         void release( Object object );
    }

The Fortress LifecycleExtension could be redefined as:

    public interface LifecycleExtension extends Creator, Accessor {}

The Merlin Extension interface would be replaced by direct use of 
Creator and Accessor.


Meta-Info Proposal
------------------

Meta-Info declaration (i.e. type level information included in an .xinfo 
file) in an extension hamdler.  This is basically the same as the 
existing Merlin meta info declaration for an extension - the only change 
is that the extension does not declare which lifecycle stages it 
supports (because we can get this info from the class if we use the 
above interfaces).

    <type>

      <!-- component, dependency, service declarations, etc. -->
      <extensions>
        
        <!-- a type may provide implementation of multiple extensions -->
        <extension>

           <!-- extension stage name and interface reference -->
           <name>exploitable</name>
           <reference type="Demonstratable" />

           <!-- optional extension attributes -->
           <attributes>
             <attribute key="status" value="experimental"/>
           </attributes>     

           <!-- declaration of the context values required by the 
extension -->
           <context>
              <entry key="home" type="java.io.File"/>
           </context>

        </extension>
      </extensions>    
    </type>

If this all sounds reasonable I'll go ahead and put it in place in Merlin.

Cheers, Steve,

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>