Robert Burrell Donkin ha scritto:
On Tue, Sep 2, 2008 at 10:32 PM, David Jencks <[EMAIL PROTECTED]> wrote:
<snip>
FWIW although you have to supply some metadata (currently via code or
annotations) Geronimo can construct components through constructor
injection: there shouldn't be any problem constructing a maillet.
I thought spring could too if you jumped through enough configuration hoops
but I'm definitely not a spring expert.
i've read that it can (spring is pretty flexible)
Using our spring-bridge you could even load mailets depending on the
ServiceManager and the avalon interfaces directly from spring.
IMHO the big change is making the mailets top level components for the
container and allow the container to deal with them by (for example)
introducing a container specific factory with a james generic interface.
Phoenix has a big limit in declaring collections of components, so
configuring a "processor" as a collection of "matcher/mailets" tuples is
not something easy in phoenix, while is trivial in spring and other
containers, even in other avalon based containers (like Plexus).
If we don't care anymore of config.xml compatibility let's start moving
self instantiated avalon component to container managed components.
We have a lot of them in the code.
A search for "ContainerUtil.service(" in our code (or more generically
for ContainerUtil) will show any place where we manually do what a
container does.
I am really really strongly in favor of constructor injection of final
fields.
i use that pattern a lot since it has good concurrency characteristics
though setter injection is much more popular
(mailets should be protected by their container so this shouldn't be
such an issue in this case)
IMHO the best approach for the mailets James ships would to be
agnostic and support both types of injection by providing appropriate
setters and constructors
the problem with mixing CDI and SDI is that CDI expect no default
constructor because a default constructor would mean that every
dependency is optional.
You can create a CDI component by simply extending an SDI component,
hiding the default constructor and add the dependencies constructor.
The opposite is not easy, you need an SDI object that wait for the
dependencies and in the init method builds the CDI and delegate to it.
Theoretically CDI is much better, I agree, but I think there are real
causes behind the SDI style being more used, and this is not because
spring didn't support CDI earlier.
Only my 2 cents.
BTW let's go ahead with the style you prefer. Refactor a CDI to an SDI
will take a lot less than this discussion already took and maybe we'll
also introduce Annotations in this discussion before we'll have a
release, so no need to discuss this "details" at this moment.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
