james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject RE: [mailets] POJOs (and in particular SieveToMultiMailbox)
Date Sun, 14 Sep 2008 20:41:44 GMT
Robert Burrell Donkin [mailto:robertburrelldonkin@gmail.com] on 13 September
2008 19:22 wrote:
> 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.

Architecurally, true. Pragamatically, I just suspect that the needs of the
Mailet lifecycle are so unique that there isn't and will never be a body of
"agnostics POJOs" out there which will benefit from this effort, so why
bother?

If I'm right, just plain old interfaces are fine. If I'm wrong, annotations
and/or XML configuration maps would be alternative ways of mapping POJO
methods to the Mailet contract.

As always, whatever scratches your itch.

Cheers

-- Steve




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