james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danny Angus <danny.an...@gmail.com>
Subject Re: [James-NG] Avalon-free James proposal and reference implementation
Date Thu, 03 Feb 2005 09:12:17 GMT
Alexander,

> Danny! I invite you to read Martin Fowlers article on IoC especially in
> the part where he explains the benefits of CDI versus Setter Dependency
> Injection.
> http://www.martinfowler.com/articles/injection.html#ConstructorVersusSetterInjection

Thank you I already read it.

> Which means to me: do not create object that have to states: created and
> initialized, rather do it in one place: constructor.

Ok but James does want to have objects which have state, and
furthermore state which can be set and reset by configuration.

You are surely not suggesting that this should result in code being
written for every possible  initial state?

Think of a matcher (or mailet which takes parameters), CDI IOC works
fine for instantiating the matcher and injecting its dependancies and
injecting it into the processor, but how do you allow an administrator
to define the processor contents, matcher patterns and mailet
parameters without writing code.

> If you need a runtime change in configuration or rather behaviour you
> should write a component that supports such change and depend your
> component on the runtime-changable-component.

Surely even this component has to receive an event to provoke the
change, and from the point of view existing James this event is a node
in an xml config file.

So yes, I agree with you so far, but I *cannot* see how we would do
away with configuration.
IOC and CDIIOC provide us with mechanisms for assembling our runtime.
What they do not,  will not, and should not do is to replace
configuration with programming.

IMNSHO and from experience of answering questions on the users list it
is important that James be easy and straightforward to configure using
mecanisms which are familiar to people who's technical knowedge of
james or java or IOC is very much less that that required to
understand the changes which they wish to make.

Examples include "how do I make james use blacklist xyz" and "how do I
make james forward mail from xxx@ to yyy@"

With all due respect to you and the great work you are doing I would
seriously resist and change to James which made the *user*
configuration of james behaviour any more complex, or require any
extra technical knowledge outside of the domain of email.

d

---------------------------------------------------------------------
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