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. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
