Berin Loritsch wrote:
>When we think if an extensible lifecycle mechanism, there are some
>requirements that we need to satisfy. Before we can determine what
>those requirements are, we also have to consider who would use them.
>That said, I will list some basic requirements for this to be
>included in Avalon, and then some more specific ones to help us come
>to a version of the support that is useable.
>
>Generic Requirements:
>
>* Must have the same interface regardless of the container
>
+1
I think of this as the stage interface. Marcus/Fortress variant is
the org.apache.excalibur.fortress.lifecycle.LifecycleExteniion
interface. Merlin's current implementation is the
org.apache.excalibur.merlin.assembly.resource.Extension interface.
There is also the notion of the Creator, Destroyer, Accessor,
Releasor from my earlier email that is designed to address the
needs of both Merlin and Fortress.
>
>* Must be included in containerkit so that new containers can easily
> support it.
>
I do agree that the meta-info parts of the solution must be
provided in a seperate meta-info resource and that resource
should be shared across containers - containerkit it not the
solution. I've mentioned this before but I'll re-state this
here - a common meta-info model should be something that is
built based on the requirements of a number of different
containers - this is what I am aiming at with the
org.apache.excalibur.meta package. The meta-info model in the
excalibur,meta package is basically the same as the mete-info
model in the containerkit package except that the excalibur.meta
package uses friendlier names arrising from the discussion on
this list way back. The excalibur.meta package does not include
any meta-data constructs (because thse are container specific).
Containerkit includes content which is meta-data based and
inappropriate for Merlin (i.e. its a Pheonix based model that's
way to rigid for Merlin style systems). You could suggest that
the solution would be to take the meta-info out of containerkit
and make it a seperate package - that's in effect exactly what
excalibur.meta is - with improvements to class naming and
documentation.
>
>* Containers must be able to say "I support/don't support extensions".
> Because the extensions would be a *standard* any container that claims
> extension support will not require the end user to implement a new
> version of the support.
>
What this comes down to is the support for a common meta-info
model. If a container support meta-info model X and X includes
the notions of extensions, then a container can choose to reject
or accept the loading of a component - the important thing it
the the cantainers understand the same meta-info model (or more
specifically, the same meta-info schema).
>Those are the basic requirements for this type of support to really be
>supported in Avalon. Use the Java mantra: "write once, use anywhere".
>We do not want two or three incompatible versions of it laying around.
>If we cannot fulfill these requirements we cannot have lifecycle
>extensions--it would be more harmful than helpful.
>
I think it would be preferable and timely to move the excalibur.meta
package up to a top level Excalibur project. The introduction of
lifecycle phase declarations and extension means that we are
breaking with the containerkit schema so we should do this
properly and put in place a schema that can evolve independently
of containerkit.
>
>Now, let's get to know the extensions user. Someone who will use
>Lifecycle extensions has a specific need that is not already supported
>by the Avalon lifecycle. It is hard to imagine such a beast, but they
>exist. Examples include web frameworks, persistence mechanisms,
>experimentation with new services, etc. Because the extension is
>aimed at a particular problem area, the developer of the system
>knows which set of extra interfaces they want to support.
>
>What we do need to guard against is an unwitting developer who wants
>to reuse a component that was designed for a certain set of extensions.
>The component will fail to operate as expected if the extension is
>not handled properly.
>
>At this point it is safe to add a couple more requirements:
>
>* New lifecycle interfaces must be marked as extensions so that we
> can determine if we can use this component.
>
I disagree - but it's probably terminology. I would say that a
component implementation must be able to declare the lifecycle
interface it is dependent on. I do not see any need to mark a
lifecycle interface as an extension.
>
>* The container *must* be able to verify if the extensions that a
> component implements can be handled. If not, we need to throw
> an exception.
>
If you mean ... a container must be able to verify that an extenion
can be established to handle a phase interface depedency declared
by a component - then I agree.
>
>* The ExtensionHandler must list the interfaces it supports to enable
> the container to verify the system.
>
Yep.
>
>Now, the question that is unclear at this point is whether we need
>more than one extension handler in any system. As Peter D. has
>pointed out, trying to maintain a separate handler for each interface
>is a maintenance nightmare. I am inclined to agree with him.
>
Ummm, over in CORBA land we are kind of use to mutliple extension
handlers. Ther isn;t any rule that says that a single extension
handler is bound to only a single extension phase interface - in
fact, the Merlin approach allows a handler to declare it support
for multiple extension phases. As to a maintenance nightmare - my
guess is that this is more related to the restrictions imposed by
the environment in which your attempting to impleemnt extension
solutions. I not experiencing any nightmares - or anything that
even looks or smells like a nightmare.
>The
>only time I can possibly think of where we would need more than one
>extension handler is if we had more than one class of components.
>Most systems have one class (Avalon pure, one set of extensions,
>or just a different component lifcycle).
>
I'm not following this too well - an extension handler is simply
a implementation that knows how to handle a particular extension
phase interface. I could reasonably have a extension phase
called Exploitable. An extension handler called ExplitationHander
contains an implementation that invokes exploit on the target
component. My system could have mutiple handlers all capable
of providing the exploitation ability to the container. The
target componet could have multiple extension phase (e.g.
Demonstratable and Exploitable). These could be serviced by
any number of combinations of extension phase providers. This
is not different to the concerpts of service dependecy and
service provision. A component can provide multiple services
and can consume multiple services - its up to the container to
resolve these. The same is true for extension phases and
extension handlers.
>Based on these observations
>I would probably add these requirements (but they are negotiable):
>
>* The ExtensionHandler should be able to handle several extensions
> at one time.
>
Disagree.
The component type being processes declares its depedency on a
extension phases. These phase declaratiuons are ordered such
that for any stage, the sequence of invocation of extension
handlers is applied in the order declared by the type for the
stages CREATE and ACCESS. The revese order is applied for the
stages RELEASE and DESTROY. The ontainer must maintain control
of the sequencing of handler stage invocations.
>
>* A component should not demand the existence of a particular
> ExtensionHandler, only that the interface is handled.
>
Agreed. However, a component my supply an selection mechainsm.
In Merlin a number of selection control mechanisms are supported
to deal with alternative selection strategies for both service
dependency candidates and extension handler candidates.
>
> - If a component expects a certain order for the lifecycle,
> we need to verify the order of lifecycle extensions. It
> might be that we need to demand a certain handler.
>
I don't think this is verification stage. Merlin approaches this
as part of the assembly process. Verification needs to ensure
that there is handler assinged for all of the extension phases
and that the assigned handlers handle the phase interface.
>
> - If two handlers satisfy a component's demands they should
> be considered interchangeable.
>
Interchangable but not equal. Merlin's default selection policy
differentiates between EXPLICIT, PACKAGED and IMPICT candidates.
Candidates are managed in terms of meta-data structures supplied
to a selector. Selectors can access meta-data and meta-info
attributes as part of the selection process. Inaddition,
meta-data contains information about the deployment status of
a particular profile. Merlin uses the same selection model for
service provider to service consumer binding as for extension
handler provider to extension phase consumer.
>
>That last requirement (with the two contridicting viewpoints)
>are the area where I believe we need to put the most work.
>
Well, from my point of view this one is easy - if fact it done,
working, demonstratable.
Cheers, Steve.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
