[logback-dev] [JIRA] Commented: (LBCLASSIC-284) Make it possible to log to different appenders at different levels from the same logger

[Alex Heneveld (JIRA)]

    [ 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:

{code}
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
{code}

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:

{code}
<root level="INFO">
  <appender-ref ref="CONSOLE" level="WARN"/>
  <appender-ref ref="FILE"/>
</root>
<logger name="acme.Main">
  <appender-ref ref="CONSOLE" level="INFO"/>
</logger>
<logger name="acme.lowlevel.SomeMarginallyInterestingTask" level="DEBUG"/>
{code}

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.

Cheers
Alex


> 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