james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: [POLL][modularisation] What About AbstractLogEnabled...?
Date Mon, 12 Mar 2007 11:02:43 GMT
On 3/11/07, robert burrell donkin <robertburrelldonkin@gmail.com> wrote:
> one of the aims of the modularisation is to factor out the container
> dependency into the deployment module. function, library and api code
> should be container agnostic. this should make the code base more
> approachable and allow the development of other container options.
> one of the major issues that's going to need to be decided is logging.
> ATM JAMES mostly uses AbstractLogEnabled for logging. this introduces
> a deep coupling to the avalon framework.
> a couple of reasonable options:
> * accept that JAMES is coupled to avalon framework through the logging API

rather not.

> * create a lighter JAMES specific replacement for AbstractLogEnabled.
> code in non-deployment modules extends that class. code in the
> deployment module (whether through byte code enhancement or manual
> subclassing) retrofits a logging aspect adapted to the framework.

absolutely preferred.

We put some thoughts into this in spring-integration branch which may
be interesting.
There, logging can be bridged (using LogginBridge) from Avalon to
probably any target logger (through adaption, implementing LogWorker).
Also, the Avalon approach of injecting different loggers for different
components is supported (LoggerToComponentMapper), although ATM only
one actual target logger is used, SystemConsoleLogWorker. All these
interfaces and classes are actually Spring-independent.

Don't know if what you are proposing is actually going one step the further?


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

View raw message