Peter Donald wrote:
>Hi,
>
>First lets use some common terminology.
>
+1
>Phoenix uses terminology
>
>* Stage - single interface like LogEnabled, Initializable
>* Phase - a set of Stages that are run in succession. ie "Startup" runs from
>LogEnabled --> Startable
>
Merlin uses the terminology
* Phase, a single interfact like Demonstratable, Exploitable, Securable
* Stage, locical step in the handling of a component's lifecycle, covering
the stages as defined by Fortress:
- CREATE
- ACCESS
- RELEASE
- DESTROY
>
>
>At various times during phoenixs evolution we have allowed both pluggable
>stages and pluggable phases. Pluggable stages lead to massive complexity,
>unmaintainable core and a big ball of mud.
>
My guess would be that Phoenix is running into issues because your
looking at a handler as something Phoenix has to be able to provide as
one of its inbuilt facilities. The Phoenix approach of seperating
internal "facilities" from "blocks" means that you inevitably have a
bootstrap problem - you facilities cannot be handled as proper fully
fledged components wheras the Merlin approach enables facilities to be
complete compoents with dependecies - they simply get treated as logical
depedencies of consumer components. Combine this with Merlin's
container hierachy management and you have the ability to cleanly
seperate facility implementations from consumer components.
>Avalon defines the "Startup" and
>"Shutdown" phases very explicitly so it is probably not a good idea to mess
>with them.
>
Just for reference - the Startup and Shutdown phase are being messed
with (but in a rather stractured manner). The CREATE extension stage
mentioned above is an addition to the Startup sequence in that the
CREATE stage is fired just before iitialize. The Shutdown sequence is
also modified in that the DESTROY stage is fired just before dispose.
>
>We ended up coming to conclusion that pluggable phases were the only real
>option. Possible pluggable phases being Management (as per phoenix),
>Instrumentation (as per ECM/Cocoon), Persistence, Session management,
>Activation etc
>
>The problems is when you come to implement it you come up against some hairy
>problems.
>
>1. For phases that require resources supplied by the container (almost all of
>them?), howdo you aquire said resources?. How do you know which MBeanServer
>to use, which PersistentStore etc.
>
The only Merlin supplied resource is the working directory reference.
Everything else is declared explicitly, packaged or derived. One of
the really nice things that's comming out of the Merlin development is
the potential for keeping Merlin as an assembly engine - what I mean is
that you should not need to get inside Merlin to be able to extend
Merlin - instead, you add extensions, facilities, tools, etc. inside the
container hierachy.
In effect this redefines "what is Merlin" to components lower down in
the container hierachy. This is possible bacause Merlin manages a
assembly left-to-right, top-to-bottom - meansing that the top level
container components are assembled, the services and extensions become
candidates for subsidiary containers. Subsidiary containers are
assembled during which parent container services may be used as service
and extension providers. As sub-container service are established, these
become availble to the parent. As a consequence, you end up with nice
control over service establishment, and clean seperation of component
implementations from service (each container is associated with its ownb
classloader which is derived from the parent classloader). During this
phase the depedenecy mapping is built and you end up with an application
- the set of relationships across the container hierachy.
>
>2. How do you "call" phases from outside the container. For instance, an
>activation/passivation phase extension will need to be able to be called from
>outside the container, as may other phases.
>
This sounds like something outside of the scope of a lifecycle
extension. The extensions being discussed are basically intercept
points in the Startup/Shudown sequence, and the lookup/release
management points. If something is callable for outside of this context
then isn't it a service published by the component in question ?
>
>
>Theres a few more hairy bits but the above are worst. As soon as you start
>defining the above you are virtually defining the container.
>
I don't think your defining the container implementation. All of the
above points are issuse that can be resolved using different approaches
- Merlin's approach seems to work. I'm currently working on some stuff
to do with the embedding of a Merlin kernel inside another compoenent to
basically validate the API for non-configuration driven solutions. In
this environemnt it would be feasible for a Merlin Kernel to be handle
meta-data supplied programatically by something like Phoenix. Merlin's
assembly process would simply scan all of the entries - and based on the
Phoenix explicit approach to predeclaration of assembly information - it
would not have to do anything beyond classic lifecycle processing.
Things like the ApplicationListener and BlockListener interfaces could
be imlemented as a lifecycle handler. If you wanted to provide for
support for extension management in Phoenix, embedding Merlin in Phoenix
could be a viable approach.
Cheers, Steve.
>
>
>On Sat, 3 Aug 2002 03:30, 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
>>* Must be included in containerkit so that new containers can easily
>> support it.
>>* 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.
>>
>>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.
>>
>>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.
>>* 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.
>>* The ExtensionHandler must list the interfaces it supports to enable
>> the container to verify the system.
>>
>>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. 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). 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.
>>* A component should not demand the existence of a particular
>> ExtensionHandler, only that the interface is handled.
>> - 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.
>> - If two handlers satisfy a component's demands they should
>> be considered interchangeable.
>>
>>That last requirement (with the two contridicting viewpoints)
>>are the area where I believe we need to put the most work.
>>
>>
>>"They that give up essential liberty to obtain a little temporary safety
>> deserve neither liberty nor safety."
>> - Benjamin Franklin
>>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
