avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: lifecycle extension proposal
Date Tue, 13 Aug 2002 17:04:50 GMT
> From: Stephen McConnell [mailto:mcconnell@apache.org] 
> 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.

A smile comes across my face :)


> 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.

A minor omission.  It can be remedied, but lets get the merger of code
done first.

> 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.

Bear in mind that something along the lines of a persistence mechanism
or a session management mechanism needs to pass in values so that the
extended lifecycles can use them.  For instance, consider a
manager that is central to Avalon.  The configuration is stored by
the ConfigManager, and retrieved from it as well.

Something like this:

interface PersistentConfigurable extends Configurable
    Configuration saveConfiguration();

The lifecycle extention handler would have to access the ConfigManager
somehow--most likely by the Context.

This would be a DISPOSE time requirement for Context.

Also session management requires both REQUEST and RELEASE access to the

interface SessionEnabled
    setSession(Session session);
    unsetSession(Session session);

On REQUEST, setSession() is called and the component can obtain all the
values it needs to continue processing for its client.  On RELEASE,
unsetSession() is called and the component can save all the values it
will need the next time it is requested.

These are very real requirements that support the requirement of having
Context accessible to all lifecycle methods.

> 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

Keep in mind that Fortress did provide an Abstract implementation that
provided null implementations for all the unneeded lifecycle methods.
That left the implementor to only implement what they need.  However
the Fortress model does not support requirements 3-5, we need to work

> 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 );
>     }


I would add the Context to each of the methods, but your exception
handling is correct.  See above for examples that require the existence
of the Context obejct.

> The Fortress LifecycleExtension could be redefined as:
>     public interface LifecycleExtension extends Creator, Accessor {}

:)  Or we can just use the Creator/Accessor like everyone else.

> 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.

It looks good to me with the one exception I already noted (existence of

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

View raw message