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 Bernd Fondermann <bf...@brainlounge.de> on 2007/09/10 09:40:36 UTC
Logging Framework for James/Spring
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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging Framework for James/Spring
Posted by Bernd Fondermann <be...@googlemail.com>.
On 9/10/07, Bernd Fondermann <bf...@brainlounge.de> wrote:
> Hi,
>
> 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 ...
I forgot one obvious choice here:
[] Avalon LogKit
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging Framework for James/Spring
Posted by Norman Maurer <no...@apache.org>.
Stefano Bagnara schrieb:
> 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).
>
I whould stick to many logs.. But rotating whould be a good step ( Unix
like). I don't like the idea to have one log filled whith do many
diffrent "stuff".
> 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.
>
Why we should do that ? I think we should use allready finish
implementations... I see no real advantage too..
> 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
>
> Stefano
>
See comments inline ;-)
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging Framework for James/Spring
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> Stefano Bagnara wrote:
>> 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.
I don't care/trust press too much (I prefer to make my own opinion by
trying things with my hands), but as I wrote I never used JUL for real,
so I think your "I worked with log4j before" is enough to have *the*
candidate :-)
In fact we don't add any hard dependency, so it will be really easy to
change this if we decide something different in future.
Thank you,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging Framework for James/Spring
Posted by Bernd Fondermann <bf...@brainlounge.de>.
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging Framework for James/Spring
Posted by Stefano Bagnara <ap...@bago.org>.
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
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
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging Framework for James/Spring
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Stefano Bagnara wrote:
> Bernd Fondermann ha scritto:
>> While commons-logging seems a good choice at first sight, after
>> thinking about it for a while, I now think we should go for the second
>> option.
>
> I'm not sure I understand: our code already directly depends on both
> Avalon-Framework-Loggers and Common-Logging-Logger.
> Is this topic to talk about the API to use in our code or the
> implementation to link from spring.xml ?
The latter. All code going into James/Phoenix is not changed for
James/Spring.
This is all about where James/Spring delegates component logs, because
in this deployment, our components get a replacement logger injected. It
acts as a bridge to any concrete logger.
This also respects what you consider an anti-pattern: having a static
Logger object declared in every class. At the same time it preserves
most of the conveniences of using all established logging frameworks.
As you point out, other frameworks might be already on the James classpath.
But as users might like to integrate James with an
environment/server/application of their choice, they'd might like the
option to use their preferred or preset API.
So, this discussion has no implications whatsoever on James' components
and James/Phoenix.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging Framework for James/Spring
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> While commons-logging seems a good choice at first sight, after
> thinking about it for a while, I now think we should go for the second
> option.
I'm not sure I understand: our code already directly depends on both
Avalon-Framework-Loggers and Common-Logging-Logger.
Is this topic to talk about the API to use in our code or the
implementation to link from spring.xml ?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging Framework for James/Spring
Posted by Bernd Fondermann <be...@googlemail.com>.
On 9/10/07, Norman Maurer <no...@apache.org> wrote:
> Bernd Fondermann schrieb:
> > What I am asking is: What framework should be the default?
> >
> I think I would use commons-logging...
>
> bye
> Norman
I'd like to describe the different levels of indirection which are
present in James/Spring to do logging:
A. Component Level
Avalon Components receive a
org.apache.avalon.framework.logger.Logger
implementation, which delegates logs to B.
B. Adaptor Level
bridge receiving component logs, delegating logs to C.
C. Concrete Logger
Currently the only implementation present is writing to System.out
If we'd add commons-logging here, and nothing else, we'd just add
another level of indirection,
changing the architecture above to
A. same as above
B. same as above
C. Commons-Logging Adaptor Level
bridge from module-specific bridge to whatever concrete API is
discovered and chosen by commons-logging
Disadvantage: The user is left with the choice of a concrete logging
API and its proper configuration.
We could either add another level of indirection:
D. Default Concrete Logger
configured to be discovered by commons-logging and do the final logging.
Or remove commons-logging from the picture at level C. and have
C. Use concrete Logging API (not commons-logging)
logs according to its configuration
While commons-logging seems a good choice at first sight, after
thinking about it for a while, I now think we should go for the second
option.
I personally favor log4j, but I don't have a strong opinion about that.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging Framework for James/Spring
Posted by Norman Maurer <no...@apache.org>.
Bernd Fondermann schrieb:
> 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
Hi Bernd,
I think I would use commons-logging...
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Logging Framework for James/Spring
Posted by Serge Knystautas <sk...@gmail.com>.
On 9/10/07, Bernd Fondermann <bf...@brainlounge.de> wrote:
> [] commons-logging
> [ +1 ] log4j
> [] java.util.logging
> [] plain file write (poor man's own framework)
> [] slf4j
> [] ... other ...
I don't see the need to use a wrapping log library and think log4j is
rather widely used. I'm reasonably familiar with it.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org