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 Thu, 04 Sep 2008 16:51:41 GMT
On Thu, Sep 4, 2008 at 10:03 AM, Stefano Bagnara <apache@bago.org> wrote:
> 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?

yes

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

yes

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

yes

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

your question confused me

>>>>>>> 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 doubt that many mailets have optional assembly dependencies. if they
do, then alternative constructors could be provided.

- robert

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