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: Logging Framework for James/Spring
Date Mon, 10 Sep 2007 08:56:00 GMT
Bernd Fondermann ha scritto:
> Hi,
> We need a proper Logging Framework integrated with the spring-deployment
> module.
> Currently, all logging is going to System.out.
> I'd like to have at least log messages to go to a single file
> 'james.log' but also support the possibilty for current phoenix-like
> behavior of multiple files.
> Logging in spring-deployment is pluggable, so every framework should fit
> and be easily added.
> What I am asking is: What framework should be the default?
> Here is a list:
> [] commons-logging
> [] log4j
> [] java.util.logging
> [] plain file write (poor man's own framework)
> [] slf4j
> [] ... other ...
> Thanks for your comments,
>   Bernd

I'm a bit confused by the question because some of them provides an api
and multiple implementations, some of them simply provide wrapping over
some of the other.

I don't have a clear vision on the better solution, so I try to write
some simple considerations:

I don't think we directly need slf4j if we keep using dependency
injection for the loggers, but maybe some of our dependencies
depends/will depends on some specific logging framework not using DI
(almost every log framework but avalon doesn't support DI). Slf4j could
save us life years dealing with classloader issues (please note that I
stopped using it at 1.0.4, I don't know if 1.1 finally fix this problem).

I think we already have commons-logging in classpath because some of the
newer components use commons-logging api. We also have
avalon-framework-log as a core dependency (IIRC we agreed to move from
avalon logger to a dependency-injection based commons-logging as a
refactoring for older components). Both of them provide an api layer and
interfaces so we can decide an implementation at any time.

As the default/simple implementation I would probably go for a single
log: in this years I noticed many users don't even recognize we have a
logs directory or are lost between so many logs. Having one single log
would save us from telling them "look into jamesserver/apps/james/logs,
the interesting log should be the smtpserver*, or mailet*" and so on.
But even if we choose a single logfile, it would be better to have
rotation (and maybe compression).

IIRC commons-logging 1.0.4 did not directly support writing a single
file but only to System.out/err.

Other: "logkit" is no more mantained and not well known, "logback" is
cool but it is LGPL so we should leave this option to the advanced user.

So, unless commons-logging 1.1 didn't introduce some new
SimpleFileLogger or something similar I think we should probably go with
 JUL or log4j. Of course log4j and JUL should only be referenced by
spring and we should not have any code directly bound to log4j and JUL.

Writing our own plain file writer (poor man's) with some option for the
log level and for the rotation would probably reduce the download size
but would require much more time and no real advantage for our users.

I never used JUL for real, so I don't know what are the issues with it.
IIRC JUL FileHandler does support rotation, log levels.

I think that code already exists to provide both JUL and log4j based
Avalon-Logger and Commons-logging logger (avalon-framework-impl provides
org\apache\avalon\framework\logger\Jdk14Logger and
org\apache\avalon\framework\logger\Log4JLogger, commons-logging provides
org\apache\commons\logging\impl\Jdk14Logger and

To summarize, currently here is my ordered list of preferences:
1) JUL with a single rotating file configuration
2) log4j


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

View raw message