[logback-dev] [JIRA] Commented: (LBCLASSIC-284) Make it possible to log to different appenders at different levels from the same logger
Alex Heneveld (JIRA)
noreply-jira at qos.ch
Mon Dec 5 12:22:14 CET 2011
[ http://jira.qos.ch/browse/LBCLASSIC-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12324#action_12324 ]
Alex Heneveld commented on LBCLASSIC-284:
+1 -- this would be very useful!
My use case is that I like to have _important_ INFO logged to the console, along with WARNs, but nearly all INFO and selected DEBUG logged to a file. For example:
acme.Main to console: INFO
acme.Main to file: INFO
acme.lowlevel.SomeMarginallyInterestingTask to console: WARN
acme.lowlevel.SomeMarginallyInterestingTask to file: DEBUG
everything else, to console: WARN
everything else, to file: INFO
This seems a handy use case for people who want console output to be pretty clean. Currently logback doesn't elegantly support this AFAIK; Iwein's workaround using filters is impressive :) but like him I think a "level" field is warranted it. I could then just say:
<appender-ref ref="CONSOLE" level="WARN"/>
<appender-ref ref="CONSOLE" level="INFO"/>
<logger name="acme.lowlevel.SomeMarginallyInterestingTask" level="DEBUG"/>
I'm happy to work on implement this. It looks a reasonably easy and low-impact change. But is this something you (the logback project) would like?
Here is my thinking on implementation:
In AppenderRefAction, look for attributes (e.g. level) and pass this to those Appenders which implement a new interface method, one of:
* AppenderRefContextAware.configureForAppenderRefContext(InterpretationContext ec, Attributes attribute)
* LoggerAppenderRefContextAware.onLoggerAppenderRef(Logger, Level)
* LoggerAppenderRefContextAware.onLoggerAppenderRef(Logger, Attributes)
AppenderBase will then have the option of paying attention to the level on a per-logger-category basis.
(Such a configuration will cause a bit of a performance overhead, but not much actually; log_2(numLoggersWithCustomCategoryAtAppender) if we used a sorted map and did binary lookup on the logger-name; cost is certainly worth it for me, and of course impact will be negligible if turned off.)
(Q1) What signature/name should this interface take? third one gets my vote for flexibility to allow appenders to specify other per-logger attributes, although I'm new to this codebase; the first one could be nice to allow XML element extensions inside appender-ref, but more work.
(Q2) Should we warn/error if there is an attribute which isn't supported? seems like we should, but currently we don't.
Next, where this is used, we are likely/certain to encounter duplicate appenders as a consequency of additivity, if we override an appender-ref level for a given category. FWIW these duplicates have always seemed to me a messy part of the framework.
(Q3) Could we add a "squash" attribute (boolean) to Logger which would "prevent a given appender from being referenced more than once for a given logger, otherwise respecting additivity settings"; functionally, it would cache the relevant appenders (i.e. inherited ones, if additivity true; doing this lazily on first access post-configuration), remove duplicates, and set this as the contents of Logger.aai? This seems a straightforward and self-contained addition to Logger.
(Q4) Is there a requirement to allow parent loggers getting new appenders post-configuration? I think so, so we'll need a notification scheme like Logger.handleParentLevelChange (probably marking dirty and forcing lazy-load on next log) but again this seems straightforward and self-container to Logger.
(Q5) For backwards compatibility squash would default to false. But would anyone really mind if it defaulted to true? (As the manual jokingly suggests, this can be a trap for new users!)
Does this seem sensible? Appreciate any guidance on these questions.
> Make it possible to log to different appenders at different levels from the same logger
> Key: LBCLASSIC-284
> URL: http://jira.qos.ch/browse/LBCLASSIC-284
> Project: logback-classic
> Issue Type: Improvement
> Affects Versions: 0.9.28
> Reporter: Iwein Fuld
> Assignee: Logback dev list
> I found a requirement in the wild to log trace and above statements to one appender, and debug and above to another. This needed to be configured for a particular package. My preferred solution would be to use something like https://gist.github.com/1104145, but that doesn't work.
> There is a workaround of using a filter inside the appender, but that isn't as pretty as I would like. ( http://iweinfuld.posterous.com/ )
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
More information about the logback-dev