Robert Burrell Donkin ha scritto:
On Wed, Sep 3, 2008 at 12:03 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin ha scritto:
On Tue, Sep 2, 2008 at 10:32 PM, David Jencks <[EMAIL PROTECTED]>
wrote:
<snip>
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.
i've read that it can (spring is pretty flexible)
Using our spring-bridge you could even load mailets depending on the
ServiceManager and the avalon interfaces directly from spring.
IMHO the big change is making the mailets top level components for the
container and allow the container to deal with them by (for example)
introducing a container specific factory with a james generic interface.
Phoenix has a big limit in declaring collections of components, so
configuring a "processor" as a collection of "matcher/mailets" tuples is not
something easy in phoenix, while is trivial in spring and other containers,
even in other avalon based containers (like Plexus).
that's not the approach i'd take
i think that we just need to add extensibility to the top level avalon
aware processor
loaders should be responsible for:
1. assembling mailets and matchers
2. mapping names to assembled instances
processors should be responsible for:
1. taking mailets and matchers instances from the loader and linking
them together into a single processing unit
2. ensuring that the mailet lifecyle is correctly propergated to all
contained mailet and matcher instances
I'm not sure I understand who configures mailet/matchers instances.
I can have multiple ToRepository with different configurations in a
single container.
ATM the LinearProcessor ask to MailetLoader "give me a mailet named XXX
configured with this avalon Configuration object".
Does "2. mapping names to assembled instances" mean that the loader will
load a ToRepository1, ToRepository2, ToRepositoryN and the
LinearProcessr will ask for the named instances?
a limit number of SPIs will need to be passed through to loaders. when
used in an avalon envionment, an avalon aware layer will be needed.
If we don't care anymore of config.xml compatibility let's start moving self
instantiated avalon component to container managed components.
We have a lot of them in the code.
A search for "ContainerUtil.service(" in our code (or more generically for
ContainerUtil) will show any place where we manually do what a container
does.
i'm not persuaded that it's necessary to break configuration
compatibility at this time. typically, breaking compatibility means
committing to the creation of a much more compelling product and this
would push back any hope of a 3.0 release for many months.
So you create alternative implementations for this? I'm not following
you at all...
I am really really strongly in favor of constructor injection of final
fields.
i use that pattern a lot since it has good concurrency characteristics
though setter injection is much more popular
(mailets should be protected by their container so this shouldn't be
such an issue in this case)
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.
this is untrue for the CDI containers i've used
Really? how do they deal with optional dependencies?
You can create a CDI component by simply extending an SDI component, hiding
the default constructor and add the dependencies constructor.
The opposite is not easy, you need an SDI object that wait for the
dependencies and in the init method builds the CDI and delegate to it.
again, untrue in my experience
I don't follow you here.
public class MyCDI {
private Component myComponent;
public MyCDI(DependencyA a, DependencyB b) {
this.a = a;
this.myComponent = b.getComponent("selector");
}
}
How do you wrap this in an SDI?
I mean every SDI object can be easily extended to CDI while it is not
always true for the opposite.
>> Theoretically CDI is much better, I agree, but I think there are
real causes
behind the SDI style being more used, and this is not because spring didn't
support CDI earlier.
most developers don't write concurrent code. they are familiar with
beans and unfamiliar with immutable value objects.
We already have an init method in the Mailet api. So we already have
something that is not CDI oriented. We should have had the MailetContext
in the constructor or in the service method otherwise.
BTW there are traces of religious issues here. I'll better wait for the
code.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
