Robert Burrell Donkin ha scritto:
On Sun, Sep 7, 2008 at 3:49 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin ha scritto:
On Fri, Sep 5, 2008 at 10:37 PM, Steve Brewin <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin [mailto:[EMAIL PROTECTED] 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
