Robert Burrell Donkin [mailto:[EMAIL PROTECTED] on 13 September 2008 19:22 wrote: > On Mon, Sep 8, 2008 at 10:41 PM, Steve Brewin > <[EMAIL PROTECTED]> wrote: > > Stefano Bagnara [mailto:[EMAIL PROTECTED] on 07 September 2008 18:29 > > > >> 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 > > > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
