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.
(2) is about the way a container handles instrumentation. The problem is that we have not defined "container", nor have we defined the "standard assumed container setup", 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.
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]
