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
posting.
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.
ok.
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.
+1
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.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
