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.setMailetName(mailetName);
configImpl.setConfiguration(configuration);
configImpl.setMailetContext(new MailetContextWrapper(mailetContext, 
getLogger().getChildLogger(mailetName)));
mailet.init(configImpl);
--------
from the MailetLoader to the ProcessorList, just after the
mailet = mailetLoader.getMailet()..

right?

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

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