james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject RE: [mailets] POJOs (and in particular SieveToMultiMailbox)
Date Fri, 05 Sep 2008 21:37:29 GMT
Robert Burrell Donkin [mailto:robertburrelldonkin@gmail.com] 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.

For the reasons discussed in this post and related threads of many moons
ago, I strongly favour CDI. I would choose just one CDI style. For me, Pico
CDI is the cleanest and most powerful, but which one is less important than
choosing just one.

To accomodate other DI implementations I'd provide a set of adapter classes.
Each would convert between the expected behavior of a supported DI
implementation and the chosen CDI style. Such adapters could accomodate both
CDI and SDI styles with clear semantics. Most likely there would be some
contractual mismatches to be overcome, but they would be constrained and
resolved in the adapter rather than sprinkled throughout the code base.

Just my thoughts. Most likley you guys are way ahead of me.

Cheers

-- Steve

> On Thu, Sep 4, 2008 at 10:03 AM, Stefano Bagnara
> <apache@bago.org> wrote:
> > Robert Burrell Donkin ha scritto:
> >>
> >> On Wed, Sep 3, 2008 at 9:00 PM, Stefano Bagnara
> <apache@bago.org> wrote:
> >>>
> >>> Robert Burrell Donkin ha scritto:
> >>>>
> >>>> On Wed, Sep 3, 2008 at 12:03 PM, Stefano Bagnara
> <apache@bago.org>
> >>>> 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?
>
> yes
>
> > 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.
>
> yes
>
> > And in spring the loader.getMailet(String name) could
> simply be mapped to
> > applicationContext.getBean(name), right?
>
> yes
>
> > 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" ?
>
> your question confused me
>
> >>>>>>> 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 doubt that many mailets have optional assembly dependencies. if they
> do, then alternative constructors could be provided.
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message