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 Sat, 13 Sep 2008 18:21:49 GMT
On Mon, Sep 8, 2008 at 10:41 PM, Steve Brewin <sbrewin@synsys.com> wrote:
> Stefano Bagnara [mailto:apache@bago.org] on 07 September 2008 18:29
>
>> Robert Burrell Donkin ha scritto:
>> > On Sun, Sep 7, 2008 at 3:49 PM, Stefano Bagnara
>> <apache@bago.org> wrote:
>> >> Robert Burrell Donkin ha scritto:
>> >>> On Fri, Sep 5, 2008 at 10:37 PM, Steve Brewin
>> <sbrewin@synsys.com> wrote:
>> >>>> Robert Burrell Donkin
>> [mailto:robertburrelldonkin@gmail.com] wrote on 04
>> >>>> September 2008 17:52
>> >>>>
>> >>>>>>>>>>> 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.
>> >>>> Sorry to jump in late...
>> >>>>
>> >>>> Trying to simultaneously support both CDI and SDI styles
>> of dependency
>> >>>> injection will just lead to a very muddled set of
>> contracts. Even within
>> >>>> a
>> >>>> DI style the lifecycles differ.
>> >>> the only way i can see this stuff working anyway is be to clearly
>> >>> split into two contracts
>> >>>
>> >>> 1. assembly lifecycle: a loader loads an instance and
>> links it to the
>> >>> objects it needs. this is covered by the specification of whatever
>> >>> assembly tool is used.
>> >>> 2. mailet lifecycle: once the instance has been
>> assembled, the mailet
>> >>> engine manages the lifecycle of the instance as a mailet. this is
>> >>> covered in the mailet specification
>> >>>
>> >>> the assembly lifecycle would be governed by container
>> used to load the
>> >>> instance. this might use JNDI, GBean, spring, avalon, OSGi. some
>> >>> mailets may only support a single assembly mechanism but
>> IMHO james
>> >>> mailets should try to be agnostic POJOs.
>> >> I think we should suggest a preferred style, but we can
>> defer this choice to
>> >> the moment we'll define "official" SPI for
>> >> mailrepository/users/xml-sql-datasrouces access.
>> >
>> > IMO it's not worthwhile getting into a religious war: we should just
>> > design our mailets to be as re-usable as possible.
>>
>> +1 and I just want to say that I'm happy with CDI too. Your arguments
>> was convincing. Steve point about choose one style instead of doing
>> something in the middle is something I completely agree with, too.
>>
>> Stefano
>
> All good to hear.
>
> I am convinced of the multiple container adapter story, I am less conviced
> of Robert's "james mailets should try to be agnostic POJOs" as I cannot see
> a generic solution. In truth, POJOs are rarely so plain. How can we adapt
> from the unknown contracts of any POJO to the Mailet contract? Only the
> POJO's implementor can know how to do that.

one standard approach is to push this onto the deployer of the
component. the implementor creates and documents the requirements of
the component. the container support some general assembly mechanism
(spring, JNDI, OSGi, pico etc) which the deployer of the component
uses to ensure that it's requirements are met.

- 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