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 18:52:39 GMT
On Wed, Sep 3, 2008 at 11:45 AM, Stefano Bagnara <apache@bago.org> wrote:
> David Jencks ha scritto:
>>
>> On Sep 2, 2008, at 12:46 PM, Robert Burrell Donkin wrote:
>>>
>>> On Tue, Sep 2, 2008 at 9:53 AM, Stefano Bagnara <apache@bago.org> wrote:
>
>>>>> Robert Burrell Donkin wrote:
>>>>>
>>>>> ATM AIUI the mailet specification is silent on assembly and service
>>>>> acquisition. one advantage of this strategy is that it's possible to
>>>>> alter these characteristics without altering the mailet specification.
>>>>
>>>> True and False... there was not support anything using services will not
>>>> work on current containers. So let's say "there's no way to be backward
>>>> compatible, so we can do whatever we want" ;-)
>>>>
>>>> Every existing container will fail to load a mailet without a default
>>>> constructor.
>>>
>>> i'm not sure how you know that's true
>>>
>> 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.
>
> Most generic container supports CDI/SDI and other weird styles. I was
> talking of *existing* *mailet* containers. So I am talking of real code
> implementing at least a MailetContext. Of course if I write a geronimo based
> mailet container and I depend on geronimo to load mailets I can use CDI, but
> this is off topic.
> I was confuting the fact that using CDI was better than SDI because there
> was no need to alter the mailet specification.

i had intended to assert the general point that changing the way that
mailets assemble their dependencies does not require a change

>> I am really really strongly in favor of constructor injection of final
>> fields.
>
> This introduce a discussion about what is/should be final. Can a
> MailetContext be altered during execution of a mailet? Can a DataSource be
> changed? Can a MailboxSPI service implementation be altered during the
> mailet lifecycle?

one of the roles of a container builder should be to shield the
contained implementation from concurrency. the mailet specification is
weak on concurrency so using immutable structural elements makes a lot
of sense.

note that this is argument about who should worry, not what. so (for
example) if a container wanted to be able to change a mailbox
implementation during operation the the container should ensure that a
suitable proxy was passed into the mailet on construction and should
take responsibility for ensure that that substitution is performed
safely (perhaps by ensuring that service is suspended).

- 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