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 20:15:14 GMT
On Wed, Sep 3, 2008 at 9:00 PM, Stefano Bagnara <apache@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>> On Wed, Sep 3, 2008 at 12:03 PM, Stefano Bagnara <apache@bago.org> wrote:


>> 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
> I'm not sure I understand who configures mailet/matchers instances.
> I can have multiple ToRepository with different configurations in a single
> container.
> ATM the LinearProcessor ask to MailetLoader "give me a mailet named XXX
> configured with this avalon Configuration object".

i propose separating assembly concerns from basic parameterisation

the loader would be resonable for assembling an named instance. for
basic mailets (no object dependencies) this would just consist of
creating an instance. for advanced mailets with object dependencies
and a sophisticated IoC loader (for example, spring) this would
consists of create and instance and supplying appropriate
dependencies. typically, this would be driven by a configuration
document specific to the loader.

the processor would take the assembled instance and take
responsibility for the mailet lifecycles. it would read a
configuration and use it to populate the MailetConfig appropriately.

> Does "2. mapping names to assembled instances" mean that the loader will
> load a ToRepository1, ToRepository2, ToRepositoryN and the LinearProcessr
> will ask for the named instances?

this is how loading works ATM. the only difference is the assembly is
more explicit and more flexible.

>> 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.
> So you create alternative implementations for this? I'm not following you at
> all...

the whole point of a pluggable architecture is that new stuff can be
plugged in without having to break the old

>>>>> 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
> Really? how do they deal with optional dependencies?


depends on how magic they are. magic containers usually choose the
greediest possible constructor (eg pico). those using configuration
files just specify the links in there (eg spring).

- 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