RE: Lifecycle Extentions

["Farr, Aaron" <Aa...@am.sony.com>]

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. 

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).

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.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org