james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [mailets] POJOs (and in particular SieveToMultiMailbox)
Date Wed, 03 Sep 2008 11:03:15 GMT
Robert Burrell Donkin ha scritto:
> On Tue, Sep 2, 2008 at 10:32 PM, David Jencks <david_jencks@yahoo.com> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message