...From: Berin Loritsch [mailto:[EMAIL PROTECTED]
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 done.
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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
------------------------------------------------------------------------------------------------------------------------------------------ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
