Farr, Aaron wrote:
Attempting to answer my own questions:
A few questions on lifecycle extentions:
1. Can Extentions (ie- something that extends AbstractCreator) implement
lifecycle methods themselves?
Merlin: yes Fortress: no Phoenix: Doesn't do lifecycle extensions
Next round:
1. Is there any plan on adding this to phoenix? 2. As for Fortress, extensions are just held in an array list and you would have to extend the DefaultContainer, directly handle their lifecycles, and then add them to the extensions list. Is there a more elegant way?
2. Is there anyway to get a handle on the component's meta-data as it's
being passed through the lifecycle extention?
Looks like that's a no.
Extensions only get the component object itself and the context. I suppose
it's possible one could hook the meta-info into the context somehow, but
that seems ugly. Is it unreasonable to ask that extensions have access to
this information? I would say yes, but unfortunately there's no standard
meta-info API between containers.
The reasons that the meta package is seperated out within Merlin is explicity to facilite the use of the package by other containers. I have been thinking recently that the package could be made smaller my moving the meta-data classes out (model package) - this would leave just the component type meta classes and builders which is 100% container independent.
One hack would be to supply the component's configuration information to the extension, but it doesn't seem like that sort of thing should belong there. Instead, this sort of meta-data probably goes along with Merlin's appliance attributes (so I suppose there's almost a solution for Merlin).
This could be done but it would be container specific (at least specific to containers that use the assembly package).
These sorts of features could really enhance the lifecycle extension API.
It would allow users to extend containers without having to actually extend
the container class and, perhaps more importantly, do so in a container
agnostic way.
Yep.
The big picture here is that a lifecycle extension *is* an extension of the containment semantics. Possible evolution could be the addition of a Type argument (nothing terribly dramtic there). I don't think the Appliance is sufficiently mature at this stage - probably more thinking needed about the interface, some reduction of exposed methods, etc. - before thinkning too much about escalating this as a common container side interface. But I also think its a good starting point.
Cheers, Steve.
This would make my MessageDrivenService idea very simple (see original email on users list). The JMS onMessage() is really a lifecycle method and it'd would be nice to find a way to include it without having to customize Fortress, Phoenix, and Merlin in case I want to swap containers (which I do). Of course I could always write a custom block or service, but lifecycle extensions seem like a more elegant solution.
I'm forwarding this to the dev list to see if I get more of a response.
jaaron
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
