Robert Burrell Donkin ha scritto:
On Wed, Sep 3, 2008 at 9:00 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin ha scritto:
On Wed, Sep 3, 2008 at 12:03 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
<snip>
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".
i propose separating assembly concerns from basic parameterisation
the loader would be resonable for assembling an named instance. for
basic mailets (no object dependencies) this would just consist of
creating an instance. for advanced mailets with object dependencies
and a sophisticated IoC loader (for example, spring) this would
consists of create and instance and supplying appropriate
dependencies. typically, this would be driven by a configuration
document specific to the loader.
the processor would take the assembled instance and take
responsibility for the mailet lifecycles. it would read a
configuration and use it to populate the MailetConfig appropriately.
So, you want to move this code:
-------
MailetConfigImpl configImpl = new MailetConfigImpl();
configImpl.setMailetName(mailetName);
configImpl.setConfiguration(configuration);
configImpl.setMailetContext(new MailetContextWrapper(mailetContext,
getLogger().getChildLogger(mailetName)));
mailet.init(configImpl);
--------
from the MailetLoader to the ProcessorList, just after the
mailet = mailetLoader.getMailet()..
right?
Do you want to remove "Configuration" from the getMailet parameter list
as it would not be used anymore?
In this case the Mailet/Matcher loaders would no more depend on
MailetContext but would only be a simple object factory for "Named" objects.
And in spring the loader.getMailet(String name) could simply be mapped
to applicationContext.getBean(name), right?
If I understood, this time, it make sense.
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?
this is how loading works ATM. the only difference is the assembly is
more explicit and more flexible.
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...
the whole point of a pluggable architecture is that new stuff can be
plugged in without having to break the old
Is this a "yes" ?
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?
yes
depends on how magic they are. magic containers usually choose the
greediest possible constructor (eg pico). those using configuration
files just specify the links in there (eg spring).
So you propose to have setters for each dependency, a default
constructor and a constructor with all of the dependencies and leave out
the declaration of what is needed and the container specific
configuration will deal with special cases.
I'm fine with this.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
