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 Thu, 04 Sep 2008 09:03:10 GMT
Robert Burrell Donkin ha scritto:
> 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:
> <snip>
>>> 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.

So, you want to move this code:
MailetConfigImpl configImpl = new MailetConfigImpl();
configImpl.setMailetContext(new MailetContextWrapper(mailetContext, 
from the MailetLoader to the ProcessorList, just after the
mailet = mailetLoader.getMailet()..


Do you want to remove "Configuration" from the getMailet parameter list 
as it would not be used anymore?

In this case the Mailet/Matcher loaders would no more depend on 
MailetContext but would only be a simple object factory for "Named" objects.

And in spring the loader.getMailet(String name) could simply be mapped 
to applicationContext.getBean(name), right?

If I understood, this time, it make sense.

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

Is this a "yes" ?

>>>>>> I am really really strongly in favor of constructor injection of
>>>>>> 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?
> yes
> 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).

So you propose to have setters for each dependency, a default 
constructor and a constructor with all of the dependencies and leave out 
the declaration of what is needed and the container specific 
configuration will deal with special cases.

I'm fine with this.


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

View raw message