'[logback-dev] [JIRA] Commented: (LBCLASSIC-82) Allow an Appender to'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       logback-dev
Subject:    [logback-dev] [JIRA] Commented: (LBCLASSIC-82) Allow an Appender to
From:       "Mike Reinhold (JIRA)" <noreply-jira () qos ! ch>
Date:       2011-05-20 14:33:51
Message-ID: 2051498039.1305902031369.JavaMail.ceki () pixie
[Download RAW message or body]

    [ http://jira.qos.ch/browse/LBCLASSIC-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12019#action_12019 \
] 

Mike Reinhold commented on LBCLASSIC-82:
----------------------------------------

Is there any update on this functionality? Not necessarily on the implementation \
presented by Robert (no offense intended), but on the concept of selection being \
re-evaluated for each logger in the logger hierarchy. It would be extremely useful \
(and, in my opinion, a common use case) for the higher level loggers, such as the \
root logger, to only log warnings or errors.

Here is a detailed description of the desired functionality which cannot (easily) be \
achieved with the selection principle as it currently exists.

Root Logger: Warn

com.app.module1 Logger: info
com.app.module2 Logger: info
com.app.module3 Logger: info
com.app.module4 Logger: info
.
.
.

com.app.module1.Class1 Logger: debug
com.app.module1.Class2 Logger: debug
com.app.module1.Class3 Logger: trace
.
com.app.module2.Class1 Logger: debug
com.app.module2.Class2 Logger: trace

In the current selection implementation, using a logging hierarchy as described would \
result in the root logger logging all of the debug and trace events for the lower \
classes. This results in a root log which is huge - most likely of unmanageable size \
to use it for practical debugging / failure analysis.

Ideally, the configuration would have an option to allow a logger to reevaluate if a \
logging request should be selected. This would allow the above scenario to work as \
desired: the root log would only contain errors and warnings, the mid-level or module \
logs would contain info messages and above, and the lower level logs could contain a \
higher level of detail. This type of functionality is critical for larger \
applications - errors and warnings should be consolidated into a single log, each \
module should have the necessary informational messages, and then class or process \
specific logs would contain detailed trace and debug messages.

Having this functionality available would allow for significantly more flexible \
logging via intermixing of loggers which do not re-evaluate the logging level \
(current functionality: aggregation point) and loggers which do re-evaluate the \
logging level (proposed functionality: filtering point). 

The configuration option would have to default to not re-evaluate logging selection \
at each logger in order to preserve compatibility with any existing applications \
which rely on the current selection functionality. Additionally, the implementation \
must very efficient in re-evaluating (or determining if re-evaluation is necessary) \
in order to prevent any significant performance degradation. 

Let me know how this fits in to your existing roadmap.

> Allow an Appender to be added to a Logger with a Level for more fine grained \
>                 control of logging output
> ------------------------------------------------------------------------------------------------------
>  
> Key: LBCLASSIC-82
> URL: http://jira.qos.ch/browse/LBCLASSIC-82
> Project: logback-classic
> Issue Type: New Feature
> Components: appender, joran
> Environment: N/A
> Reporter: Robert Elliot
> Assignee: Logback dev list
> Priority: Minor
> Attachments: AppenderWithLevelTest.java, JoranConfiguratorTest.java, logback.patch, \
> simpleAppenderLevel.xml 
> 
> Here's my use case:
> I have an appender, standard.log, whose job is to log major system events such as \
> startup and shutdown, and all problems.  I have configured my logger levels very \
> carefully to ensure I get exactly the output I want - in some cases suppressing \
> WARN messages that I know are not a problem by setting the level to ERROR, in some \
> cases allowing INFO messages that let me see important lifecycle events. A \
> simplified example might look like this: root=WARN,standard.log
> x.y=INFO
> a=ERROR
> I have a problem in a couple of parts of the system which means I want to turn on \
> debug logging for that part of the system.  I want the output of this to go to a \
> separate appender - debug.log. So now my config looks like this:
> root=WARN,standard.log
> x.y=INFO
> x.y.z=DEBUG,debug.log
> a=ERROR
> a.b=DEBUG,debug.log
> But now I have an issue; all my debug statements are going to standard.log.  It is \
> being polluted with a load of information I don't want in it. I have several \
> options: 1) Set additivity to false on x.y.z and a.b.
> But then any ERROR messages in a.b or INFO or above messages in x.y.z no longer get \
> to standard.log, so this won't do 2) Add a filter of INFO or greater to the \
> standard.log appender But then any INFO and WARN messages in a.b will get to \
> standard.log - and I only want ERROR messages from a and its descendants in there \
> 3) Add a filter of WARN or greater to the standard.log appender Now I still get the \
> WARN messages from a.b that I don't want - and I've lost the INFO messages from x.y \
> that I do want 4) Create two new appenders, standard.log2 for a and standard.log3 \
> for x.y.z.  Add a filter to standard.log2 so that it only accepts ERROR.  Add a \
> filter to standard.log3 so it only accepts INFO or above.  Set additivity to false \
> on a and x.y.z. That works.  But it's a huge amount of added configuration, and \
> that would rapidly multiply in a real world setting. 5) Create a custom filter for \
> standard.log which would effectively mirror the logger config by querying the event \
> for its logger and and level. That blows DRY out of the water, of course, and again \
> is a large amount of work for a simple use case. My suggestion to make this easy is \
> to allow Appenders to be added to a Logger with a Level.  This solution would \
> operate in parallel with the existing solution, and would not alter the existing \
> behaviour one iota. This would allow me to add debug,log as an appender on a and \
> x.y.z with a level of debug.  All debug statements in a and x.y.z & their \
> descendants would be appended to that appender.  All statements would also be \
> passed to the "normal" appender and logger hierarchy, so standard.log would still \
> get the same output as before. I have written unit tests for this behaviour and \
> attach a patch fulfilling them; I hope the unit tests flesh out any queries you may \
> have around how this behaves in edge cases. The only change to the public API is a \
> new method addAppender(Appender<LoggingEvent> newAppender, Level level) on Logger. \
> The only change to the config format is allowing an optional level attribute on \
> appender-ref.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: \
                http://jira.qos.ch/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
http://qos.ch/mailman/listinfo/logback-dev

[prev in list] [next in list] [prev in thread] [next in thread] 