On Wed, Sep 3, 2008 at 11:45 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > David Jencks ha scritto: >> >> On Sep 2, 2008, at 12:46 PM, Robert Burrell Donkin wrote: >>> >>> On Tue, Sep 2, 2008 at 9:53 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > >>>>> Robert Burrell Donkin wrote: >>>>> >>>>> ATM AIUI the mailet specification is silent on assembly and service >>>>> acquisition. one advantage of this strategy is that it's possible to >>>>> alter these characteristics without altering the mailet specification. >>>> >>>> True and False... there was not support anything using services will not >>>> work on current containers. So let's say "there's no way to be backward >>>> compatible, so we can do whatever we want" ;-) >>>> >>>> Every existing container will fail to load a mailet without a default >>>> constructor. >>> >>> i'm not sure how you know that's true >>> >> FWIW although you have to supply some metadata (currently via code or >> annotations) Geronimo can construct components through constructor >> injection: there shouldn't be any problem constructing a maillet. >> >> I thought spring could too if you jumped through enough configuration >> hoops but I'm definitely not a spring expert. > > Most generic container supports CDI/SDI and other weird styles. I was > talking of *existing* *mailet* containers. So I am talking of real code > implementing at least a MailetContext. Of course if I write a geronimo based > mailet container and I depend on geronimo to load mailets I can use CDI, but > this is off topic. > I was confuting the fact that using CDI was better than SDI because there > was no need to alter the mailet specification.
i had intended to assert the general point that changing the way that mailets assemble their dependencies does not require a change >> I am really really strongly in favor of constructor injection of final >> fields. > > This introduce a discussion about what is/should be final. Can a > MailetContext be altered during execution of a mailet? Can a DataSource be > changed? Can a MailboxSPI service implementation be altered during the > mailet lifecycle? one of the roles of a container builder should be to shield the contained implementation from concurrency. the mailet specification is weak on concurrency so using immutable structural elements makes a lot of sense. note that this is argument about who should worry, not what. so (for example) if a container wanted to be able to change a mailbox implementation during operation the the container should ensure that a suitable proxy was passed into the mailet on construction and should take responsibility for ensure that that substitution is performed safely (perhaps by ensuring that service is suspended). - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
