Berin:
Thanks for the feedback. After ready you reply I think we are down to
the single issue of context management during the access, release and
destroy stages (which is also related to the meta-info context
information).
Firstly the context separation issue
------------------------------------
The problem I have (from the point of view of a container) is that I am
dealing with a number of seperate constructed context instances:
(A) the context to provide to a target component under the
contextualize stage that is built based on the context criteria
declared in the component profile (this is the classic component
context)
(B) the context to provide to an extension under its contextualixe
stage (keep in mind that in Merlin an extension is no different
for a regular component)
(C) the context to supply to an extension when requesting stage
execution (keeping in mind that the supplied context must be
constructed by the container in accordance with type level
context criteria and profile level context value creation
directives)
In Fortress B doesn't exist because extensions are not components,
context A is uses as the value in C, however, the implementation of A
knows nothing about the context requirements of the extension - so
Fortress is basically running on hope and luck that the context
information needed during execution of a stage will be supplied by the
container. In the Merlin case the extension handler declares explicitly
the context that it needs (independently of the context that the target
component needs) and the directives for container creation of the
context values.
This ensures that extension handler components can be built and used
independently of the implementation of the target component.
To sumarise - the context values supplied to a lifecycle extension
method must be declared. Given that they are declared, then the
declaration must occur inside the type that is dependent on the value
(i.e. the extension handler implementation, not the target component,
and not the container).
On context arguments in access, release and destroy stage invocations
---------------------------------------------------------------------
In Merlin the create stage context value for an extension is produced by
the class ResourceProvider through the method createContext(
ExtensionDescriptor descriptor, Context context). This is invoked by
the stateless class LifecycleHelper. The ResourceProvider class is also
state independent of the object being managed. If context state needs
to be maintained across lifecycle stages for a given extension (e.g.
extension X needs context during create and destroy) then extension X
should maintain the refernece to the context supplied during create. In
the examples provided, all of these appear to use the same context
instance across the different stages - as such, I don't see a problem
with pushing the obligation onto the extension handler for maintaining
the reference to the context instance over its lifetime.
If (and this is a big if) - an extension needs to be suppplied with
different context information at different stages, then a lot more
detail will be needed in the meta-info and meta-data models then we have
at the moment. This is also something I would *really* not like to support.
.... more notes in-line
Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>
>>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 :)
>
>
><snip/>
>
>
>
>>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 configuration 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.
>
In Merlin, the peristence extension is required to declare the
context values that it requires. It may also declare directives
through which a container can create these context values. The
extension could also declare dependecies on other components as
part of its process of establishing the state it needs to fullfill
the extension stage execution. I.e. the container responsibility
is limited to handling context construction and component assembly.
Anything else is extension resposibility.
In this example, a ConfigManager has to be created. A ConfigManager
is unknow to Merlin. A ConfigManager could be created by Merlin
using context directives, or, the extension could create a manager
itself, or aquire a manager via a service dependency. Bottom line
is that the extension is resoposible for establishment of the
ContextManager instance in which case it can also hold a reference
to that instance when handling subsequent stages.
>
>Also session management requires both REQUEST and RELEASE access to the
>Context.
>
>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.
>
Having context accessible is different to passing it across an interface.
In the above example, a context value can be supplied by the container on
creation, the extension can hold a reference to this for use during the
access and release 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).
>>
>>
>
>True.
>
>
>
>
>>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
>since the Fortress model does not support requirements 3-5, we need to
>work harder.
>
>
>
>
>>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.
>
I'm still maintaining my position that this is not needed, but in the
meantime, some questions - Is it correct to asume that the context
instance is the same imutable instance for each invocation? If this isn
not true, a lot more complexity is needed in the meta-info and meta-data
model (a.k.a. lets' not go in that direction). Secondly, assuming it's
the same instances, then if the container has to cache this value (as
opposed to the extension) - (which is what your suggesting), then
basically your saying that for every component instance, the container
must maintain the context state for all of the extensions the component
is dependent on (eeek). I'm reasonably confident that you don't want to
imply that, but as far as I can see - that's the implication.
Can you enlighten me?
>
>
>
>
>>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.
>>
>>
>
>Right.
>
>
>
>>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
>Context).
>
Where else would you define the context? The context criteria is
totally independent of the object that the extension is servicing, its
independent of the serviced objects context, and its not the smae as the
context supplied to an extension in its role of component. To put it
anywhere else would be a SOC violation - see comments on this at
beginning on the email.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
