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. > 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) > To accomodate other DI implementations I'd provide a set of adapter classes. > Each would convert between the expected behavior of a supported DI > implementation and the chosen CDI style. Such adapters could accomodate both > CDI and SDI styles with clear semantics. Most likely there would be some > contractual mismatches to be overcome, but they would be constrained and > resolved in the adapter rather than sprinkled throughout the code base. adapter classes are definitely an interesting option. i think that this may be needed to support service-centric paradigms such as OSGi. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
