[
https://issues.apache.org/jira/browse/LOG4J2-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14138517#comment-14138517
]
Ralph Goers commented on LOG4J2-60:
-----------------------------------
Logger levels are always checked. Since version 2.0 (due to issue LOG4J2-441),
if a Logger doesn't have a level the level of its parent is checked. The
isErrorEnabled method will only check the Logger levels. So in the example
above you would need the Logger level set to "TRACE".
> Ability to configure log level filtering on a per <appender-ref/> basis
> -----------------------------------------------------------------------
>
> Key: LOG4J2-60
> URL: https://issues.apache.org/jira/browse/LOG4J2-60
> Project: Log4j 2
> Issue Type: Wish
> Components: Core
> Reporter: Shane Kelly
> Assignee: Ralph Goers
> Priority: Minor
> Fix For: 2.0-alpha1
>
>
> log4j 2's predecessor, log4j, supports the ability to filter log messages
> both at the <logger/> and <appender/> level (where a <threshold/> has been
> specified). This satisfies most typical scenarios, however I would find it
> very useful to have a slightly finer degree of control, such that it is
> possible to define log level filters at the <appender-ref/> level. Therefore
> for a given logger, you could have multiple <appender-ref/> definitions, each
> with their own independent log level filter. I feel this would be useful in
> scenarios where you wish messages for the same logger to be filtered
> independently depending on the destination appender, and also the ability for
> two separate loggers to write to the same appender at different log levels. A
> typical example might be were you have deployed a Web App and you require it
> log only important messages by default, perhaps WARN and above, to the server
> console (STDOUT) because you don't want to clutter it up with lots of details
> information - just the important stuff, whilst logging much more verbose
> information to a separate rolling appender - which could then be used for
> more complete analysis at a later date, should the need arise. You might also
> have a second Web App (or a 3rd partly library which supports log4j/log4j 2)
> which is configured to reuse some of all of the appenders detailed earlier,
> but with completely independent log level filtering.
> To help illustrate the general concept I'm aiming for, I've included a
> pseudo-configuration file below. You'll notice that I've omitted the LEVEL
> attribute from the <logger/> nodes and added LEVEL attributes to each of
> the <appender-ref> nodes - this doesn't work in log4j obviously, but I was
> wondering if there was some other way of emulating the behaviour that I'm
> after without cluttering up the logback configuration too much...? You can
> see from the configuration that for com.myorg.myapp.subpackage.one I would
> like to apply different log level restrictions depending on the destination
> appender. You'll also notice that for com.myorg.myapp.subpackage.two I want
> to reuse the same appenders, but also use different level restrictions....
> hope that makes it clear enough...
> ---------
> <appender name="A">
> ...
> ...
> </appender>
> <appender name="B">
> ...
> ...
> </appender>
> <logger name="com.myorg.myapp.subpackage.one">
> <appender-ref ref="A" LEVEL="INFO"/>
> <appender-ref ref="B" LEVEL="DEBUG"/>
> </logger>
> <logger name="com.myorg.myapp.subpackage.two">
> <appender-ref ref="A" LEVEL="WARN"/>
> <appender-ref ref="B" LEVEL="TRACE"/>
> </logger>
> ----------
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
