avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: More "academic" ideas [Was: [VOTE] New sandbox project]
Date Fri, 12 Mar 2004 12:48:23 GMT

> From: Stephen McConnell [mailto:mcconnell@apache.org] 
> Leo:
> Thoughts concerning the current code:
>     /**
>      * Handles singleton A4 components. Right now, we only
>      * support the LogEnabled and Serviceable interfaces.
>      */
>      public class Avalon4ComponentHandler implements
>        Handler, LogEnabled, LifecycleInterceptable, Serviceable {
> Two things based on dealing with similar stuff:
>    * separate lifestyle concerns from new instance stuff
> Basically a lifestyle handler encapsulates the decision 
> concerning when 
> a new instance is required. In the activation package you will find a 
> LifestyleManager interface, a set of implementations, and a 
> LifestyleManager factory.  The factory is supplied with a 
> ComponentFactory which deals with the setup and tearddown of 
> components. 

That makes sense - esp when considering pooling etc...

>   What I think you describing in Avalon4ComponentHandler looks to me 
> like an implementation of a component factory.


I'll check the files you mentioned - no point in reinventing the
> Second point - I think its a bad ide to use interface such as 
> Serviceable etc. to provide a ServiceManager to a factory 
> when in fact 
> the factory isn't using the manager to resolve a dependency - but is 
> instead using the object as an argument in subsequent 
> operations.

The point of doing that is that if the Handler had been a PicoHandler
instead of an A4 handler, the handler *would* have used the
to resolve dependencies. It just happened that the SM could be given to
the component directly in this case.

> Definely feel free to ignore all of the above - your in experimental 
> mode and I'm just tossing in thoughts as they occur.

Any feedback is appreciated - bring it on! Thanks for taking the time
to look at the code.


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

View raw message