Leo Simons wrote:
What is a lifecycle extension?
It is the concept
"(1) I have here this interface, which exposes some methods that are to be called somewhere in the lifecycle of a component in a well-defined manner."
it is not
"(2) I also have some code here which can do the management of this part of the lifecycle on behalf of the container."
though that is extremely useful too.
(1) doesn't need anything special:
/** this is a lifecycle extension interface! */ interface Instrumentable { setupInstrumentation( InstrumentManager manager ); }
this is IMO a very good idea, and the idea belongs in framework. It requires no code. It would be nice to have a standard way of marking an interface as being intended for lifecycle extension, but we need a metadata setup for that.
Wow - slow down - go read the instrument documetation.
A lifecycle extension is two parts:
* an interface implemented by a component that represents
a supplimentary stage (as distrinct from a work interface)
* an implementation of a handler that is capable of supporting
the stage using the contracts defined by the lifecycle
packageEnabling - protability of extensions across different containers.
(2) is about the way a container handles instrumentation. The problem is that we have not defined "container",
Not required.
Defintion of a container is not something components need to see - the lifecycle extension innterface are things that need to see by component providing plug-in support for new stages.
nor have we defined the "standard assumed container setup",
Not required.
The lifecycle extension interfaces only deal with the interfaces implemented by handlers. This is indepedent of particular container implementations. In fact if you look at Merlin and Fortress - their respective impleemntations and setup are distinctly different.
so it is impossible to define a generic way to handle lifecycle management from the container side, and also impossible to define a generic way to create plugins to assist in that management.
Correction.
It is possible - that was the objective of the project. That objective was reached. We have this working today. Remember - this is dealing with the interface contracts - its not attempting to define the total deployment scenario. I agree that more in this area can be done concerning common approaches to things like setup and so on - but that is orthoginal to the interface contracts.
Cheers, Steve.
Leo Sutic wrote:
While there are many ways to handle lifecycle extensions, there are many ways of handling configuration, initialization, contextualization, logging and so on but we still have settled on just one way in Avalon.
That there are several ways to accomplish one goal should not keep up from stating that "well, *this* is how we do it in Avalon".
+1, where "Avalon" is the project @ avalon.apache.org :D
It was my understanding that the instrument package was an extension
that
would be handled via the lifecycle extension package instead of moving
it (the instrument package) into Framework.
it is possible to manage instrumentation as a lifecycle extension using the lifecycle package moved from excalibur to sandbox and now back into excalibur. The instrument materials don't really care how they are integrated into a container. A container could opt to have a hard dependency on instrumentation, and use something as simple as
MyContainerUtil extends ContainerUtil { setupInstrumentation( Object obj, InstrumentManager im ) { /* ... */ } }
I can see the rationale for standardizing lifecycle extensions, so, in my opinion, they should definitely be in framework. Not in an extension, not in a standard extension, but in framework.
I disagree. I think the current content of the org.apache.avalon.lifecycle package should not be a part of avalon-framework.jar.
As an example, I'm perfectly okay with saying that all containers the avalon projects produces provide support for lifecycle extensions, and that they do so using the same lifecycle-extension-support-package. I'm not okay with saying that Plexus should support lifecycle extensions, and not at all with saying that it should provide support for Instrumentable packages by using that same lifecycle-extension-support-package.
to contrast, I am okay with saying that Plexus is not a compliant avalon container if it calls initialize() before service() on an object that implements both Initializable and Servicable.
Of course I'm just using the name Plexus as an example container developed outside of the avalon project which supports avalon-framework but for which I have no idea if and how it supports lifecycle extensions.
cheers!
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
