james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: 2.3.x vs trunk [WAS Re: [VOTE] Mailets -> Mailet subproject]
Date Thu, 27 Mar 2008 10:10:50 GMT
Robert Burrell Donkin ha scritto:
> JAMES uses LogKit (and so avalon framework) for logging. though LogKit
> is good, it's tied to avalon and no longer widely used. most
> developers would be much more familiar with log4j and JCL. it is
> possible to use either of these libraries in an IoC fashion which
> would continue to support area based logging.

For the record I prefer avalon-framework logging interfaces to JCL and 
log4j. Avalon's one is the only dependency injection based logging 
framework and IMHO much better than JCL and log4j.
It is easy to use log4j or JCL implementations via the avalon interfaces 
while it is not easy to do the opposite.

> JAMES has it's own bio framework based on excalibur (which is alive)
> but we've done a poor job of clearly factoring it out cleanly from
> avalon. this would not matter so much if it used delegation rather
> than inheritance.

I agree.

> many of the JAMES backends are implemented using avalon components

I agree.

>> A major area to look at is configuration.
> use of avalon as our IoC container is a major issue. we can't hide it.
> there's no spinning it. any developer who wants to code anything new
> or interesting (rather than just maintaining the existing codebase)
> has to learn avalon. this is proves too big hurdle for most.


> as far as IoC containers go, Avalon is definitely showing it's age: it
> relies on far too many configuration files and assembling components
> takes too much legroom. use of avalon to assemble JAMES might be
> usefully replaced by OSGI.

It is not avalon framework that depends on so many configuration files 
but the specific container we use (phoenix). That said I agree that 
Avalon framework "Configuration" interface is not so good and it would 
be better to move to something better. I'm not sure that OSGi will 
decrease the needed configuration files and metadata. For my experience 
OSGi instead increase it: but it is possible I used it the wrong way.


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

View raw message