[ http://jira.qos.ch/browse/LBCLASSIC-284?page=com.atlassian.jira.plugin.syste... ] 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