james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bf_...@brainlounge.de>
Subject Re: Logging Framework for James/Spring
Date Mon, 10 Sep 2007 11:07:58 GMT
Stefano Bagnara wrote:
> 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.

Sorry for the confusion, I should have been doing more thinking before 

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

ok, interesting.

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

As components interact, to analyze a particular problem you may have to 
monitor multiple log files currently with James/Phoenix, which is not 
very convenient. I like to do "tail -f server.log" and watch this in a 
window. So I would opt for a single file.

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

this was only listed for those who don't want any API introduced at all. 
I am not amongst those.

> 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
> org\apache\commons\logging\impl\Log4JLogger).
> To summarize, currently here is my ordered list of preferences:
> 1) JUL with a single rotating file configuration
> 2) log4j

I'd reverse the list, simply due to bad press jul received recently (I 
don't know it) and because I worked with log4j before.


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

View raw message