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.
For the reasons discussed in this post and related threads of many moons
ago, I strongly favour CDI. I would choose just one CDI style. For me, Pico
CDI is the cleanest and most powerful, but which one is less important than
choosing just one.
:-)
(i'm a big pico fan too)
I could become a pico fan too since they have this in an optional component:
https://svn.codehaus.org/picocontainer/java/2.x/trunk/logging/src/main/java/org/picocontainer/logging/Logger.java
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
