[
https://issues.apache.org/jira/browse/LOG4J2-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14138508#comment-14138508
]
Vinay commented on LOG4J2-60:
-----------------------------
One question, so with a configuration
<logger name="com.myorg.myapp.subpackage.two">
<appender-ref ref="A" LEVEL="WARN"/>
<appender-ref ref="B" LEVEL="TRACE"/>
</logger>
If check is made for isErrorEnabled, then will it look into all the appenders
or will it still check at logger level i.e. for com.myorg.myapp.subpackage.two
and return.
> 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]
