You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by robert burrell donkin <ro...@gmail.com> on 2007/03/11 09:15:26 UTC
[POLL][modularisation] What About AbstractLogEnabled...?
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
* 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.
opinions?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [POLL][modularisation] What About AbstractLogEnabled...?
Posted by robert burrell donkin <ro...@gmail.com>.
On 3/12/07, Bernd Fondermann <be...@googlemail.com> wrote:
> On 3/11/07, robert burrell donkin <ro...@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?
not sure i'm proposing, just analysing :-)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [POLL][modularisation] What About AbstractLogEnabled...?
Posted by Bernd Fondermann <be...@googlemail.com>.
On 3/11/07, robert burrell donkin <ro...@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?
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [POLL][modularisation] What About AbstractLogEnabled...?
Posted by Stefano Bagnara <ap...@bago.org>.
Avalon way (to inject the logger as any other service) is my preferred
approach to logging. I really don't understand why this pattern is not
used by every other logging framework.
In jSPF instead we added our own Logger interface, but I think that this
is not a good solution if everyone start adding new "cloned" interfaces.
We did this because jSPF was not bound to Avalon, so we simply took the
Logger interface from there and used for our purpose (with injection).
I would avoid the "standard" use of static methods inside classes to
lookup the logger (Logger.getLogger / Log.getLogger) and I prefer to
keep dependency injection for the logger service. We could inject
something different from Avalon Logger and then use a wrapper to keep
compatibility with the current components/container.
e.g: refactor our components to expect a Commons-logging logger (like
IMAP classes do) to be injected. We can then use a wrapper (it already
exists in our codebase, because of IMAP stuff, IIRC).
The main "problem" with this solution is the lack of getChildLogger in
commons-logging: we make use of it (not too much, but we do). Joachim
introduced the MyLogFactory interface as a solution to this issue.
Another approach is to avoid the use of getChild by using always
container managed components or using container managed factories when
we need "wired" sub-components.
Stefano
robert burrell donkin ha scritto:
> 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
> * 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.
>
> opinions?
>
> - robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org