Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>
>>Marcus Crafter wrote:
>>
>>
>>
>>>What's the latest on the Merlin/Fortress merger ? Was there any
>>>progress there while I was away ?
>>>
>>>
>>>
>>The latest Merlin news is the completion of pluggable lifecycle
>>extensions.
>>
>>
>
>
>Are you using the same (or essentially the same) classes as in Fortress?
>
I started off with the Fortress classes and progressively eliminated
them - not by choice but more out of seperation of what's container
concern from the extension issue. What I came down to was one interface
that needs to be published - the rest is an implementation issue. The
published interface is:
public interface Extension
{
public static final int CREATE = 0;
public static final int ACCESS = 1;
public static final int RELEASE = 2;
public static final int DESTROY = 3;
/**
* Apply lifecycle phase extension.
*
* @param stage the lifecycle stage
* @param object the object to apply the extension to
* @param context the context
* @exception Exception if an error occurs
*/
void extend( int stage, Object object, Context context )
throws Exception;
}
The differnce between this and the Fortress variant is that the above is
more generic - the actual "stages" that a implementation of Extension
supports is declared in the meta-info model - whaeras the Fortress
variant is invoked for ever stage. Merlin is a little smarter in that
it only invoke the stages that the extension implementation needs to
handle to support the phase. But as you can see - it's following the
same principals as Fortress.
>If so, we need to look at moving that into ContainerKit sooner than
>later. Something like this should be done once by a developer and
>reused in whatever other container.
>
I've incorporated the meta-info stuff into org.apache.excalibur.meta.*.
This builds a seperate jar file excalibur-meta-1.0.jar so that the meta
info model is reusable across any other container. The meta-data model
and machinery that handles assembly is packaged inside the merlin.jar
file. I don't think that moving this into containerkit is a viable
proposition - firstly, containerkit combines both meta-ifo and meta-data
into a single jar - and the containerkit meta-data model just isn't a
workable proposition for Merlin. Containerkit meta-data classes require
that the complete association network be known before the meta data is
put together (a.k.a. - Phoenix assembly.xml). Merlin takes a completely
different approach - it hunts around to find the set of potential
candidates - provides mechanisms for ordering and selection of
candidates, and incrementally builds the application model by
dynamically assigning association between potential types.
>
>For a feature like this, it is not as important that the feature exists,
>but that the feature is useable across all new containers. Trying to
>support two different sets of classes that do the same thing is not
>good, nor is it compatible.
>
Agreed.
However - some points to consider. Merlin does not provide the notion
of an LifecycleExtensionManager - that's because lifecycle extensions
are regualar components and are treated as such during assembly - thay
just happen to declare extension capabilities and merlin handles the
wiring together of these capabilities with other components that need
these capabilities. As far as Fortress is concerned - this means a code
dependecy on the meta-info model - and that's more related to
RoleManager than anything else.
Cheers, Steve.
>
>What do you say?
>
>
>
>P.S. I will look at the rest of the stuff RSN. I just wanted to get
>this
>part cleared up.
>
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
