avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [RT] Distant Future...
Date Wed, 23 Jul 2003 14:54:34 GMT
Leo Sutic wrote, On 23/07/2003 16.09:

>>From: Berin Loritsch [mailto:bloritsch@apache.org] 
>>how do we improve on our current model?
>     I want simplification, and I think PicoContainer does that.

I want simplification too, but IMHO PicoContainer, although interesting, 
still doesn's cut it.
>     + How do we provide components?
>       PicoContainer passes them in the constructor. A4 requires a
>       lookup()/release(). I'd like to just mark a public field with
>       the dependency info and have that field set by reflection to 
>       a reference. Like this:
>       class MyComponent {
>           /**
>            * @avalon.dependency version="1.0"
>            */
>           public QueueManager queueManager = null;
>           ...
>       }
>       This would have the queueManager field set by the container to
>       a QueueManager with version 1.0. Yes, this means exposing public
>       fields, but seriously, how many check that compose() isn't called
>       more than once? It is the responsibility of the container to
>       proxy components and protect them.

Hey, I had the same idea! Cool!

Probably we could also be able to set private fields (IIUC BCEL can do 
it), and that would be the best.

But this is only part of the equation, that of servicing a component. It 
seems that the lifecycle is not taken into account.

That is what extensions can be for: imagine that we don't have mandatory 
(although we can still keep suggested ones) interfaces for the 
lifecycle. And that we can plug in extensions that can run in particular 
stages. We don't need coupling anymore, as these extensions can run on 
complete reflection and external definitions.

For example, I can instruct my container to add a lifecycle extension 
that is called in the components that have an init method. The extension 
would simply call that method.

Or I can instruct my container to add a lifecycle extension that is 
called in the components that have a service(ServiceManager) method. The 
extension would that method and give the ServiceManager.

As you see, we can run *any* component in the container, even ones that 
were not made for Avalon and that have particular lifecycle stages to be 

Why are you so against extensions?

>>Does this plan sound good?
> If it means that all the meta info generators can finally be
> dumped on the world's biggest scrap heap then I'm all for it.

+1  Definately.

Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message