[logback-dev] [JIRA] Commented: (LBCLASSIC-82) Allow an Appender to be added to a Logger with a Level for more fine grained control of logging output

[Mike Reinhold (JIRA)]

    [ 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