james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: [mailets] POJOs (and in particular SieveToMultiMailbox)
Date Wed, 03 Sep 2008 19:29:48 GMT
On Wed, Sep 3, 2008 at 12:03 PM, Stefano Bagnara <apache@bago.org> wrote:
> 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).

that's not the approach i'd take

i think that we just need to add extensibility to the top level avalon
aware processor

loaders should be responsible for:

1. assembling mailets and matchers
2. mapping names to assembled instances

processors should be responsible for:

1. taking mailets and matchers instances from the loader and linking
them together into a single processing unit
2. ensuring that the mailet lifecyle is correctly propergated to all
contained mailet and matcher instances

a limit number of SPIs will need to be passed through to loaders. when
used in an avalon envionment, an avalon aware layer will be needed.

> 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'm not persuaded that it's necessary to break configuration
compatibility at this time. typically, breaking compatibility means
committing to the creation of a much more compelling product and this
would push back any hope of a 3.0 release for many months.

>>> 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.

this is untrue for the CDI containers i've used

> 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.

again, untrue in my experience

> 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.

most developers don't write concurrent code. they are familiar with
beans and unfamiliar with immutable value objects.

- robert

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

View raw message