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.
For existing containers there was an implicit "mailets have a default
constructor" and the 2 existing containers + the mailet-report-plugin
already depends on this. They will throw bad errors if you give them a
mailet with not default constructor.
Easy to change, but this is not the "current" case, so I don't this this
is something that move a choice between CDI and SDI.
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?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
