From: Berin Loritsch [mailto:[EMAIL PROTECTED]
how do we improve on our current model?
I have been meaning to write an [RT] about this, but the approach taken in PicoContainer, is, I believe, the future.
1. To clarify that a bit - lifecycle extensions and all are good, but ***my God do they add complexity***. Anything that requires documentation to use phrases like "establishing a deployment context" is in dire need of simplification.
They can be simplified. Don't worry, we can add features without adding too much complexity.
I still use the ECM, because, frankly, I don't "get" the other
containers. I understand them but it's just too much to
comfortably keep inside my head.
That's because you haven't used them enough to appreciate what the features do for you. Once you start taking advantage of it, you get hooked.
I want simplification, and I think PicoContainer does that.
I want simplification too, however, I need a pointer to PicoContainer because I am not aware of it being in Avalon's CVS. We can find the balance when it is time though. For now, let us just say that much of the need for our fancy libraries will most likely be removed by the official language features of Java 1.5. Not to mention our need for other external libraries will be reduced as well.
2. I think there are some lingering issues with A4 that we should revisit, for example:
+ Poolable components
This is the whole reason for the lookup()/release() in ECM and
Fortress. I think we can come up with some other idiom, maybe
component.beginTransaction ();
try {
... do stuff ...
} finally {
component.endTransaction ().
}
That will allow us to actually do all the lookup() in the equivalent of compose()/service(), instead of limiting that method to a single this.myServiceManager = manager; line.
I agree that we should look at them. However, I think we are kind of stuck with our interface for the time being. I would prefer something that didn't require a try/finally approach because we are imposing too much on the developer. Remember simplicity--and the question becomes for who are things simplified?
+ 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.
There are other ways of doing the same thing. My version of simplicity will allow the container to adapt so that there are very little real requirements on the component writer. I.e. the container would be able to work with Avalon components, Pico style components, etc. etc.
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.
Language features take care of this function. Unless you *use* the meta info, the simplicity that it offers the component writer is lost on you. It truly is vastly more convenient to manage your component directly in the source code than it is to have to edit a roles file and a config file.
Again, simplicity should be one of the major themes of Avalon 5--but we aren't anywhere near there yet. For the time being, let us focus on Avalon 4 and make it better.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
