[
https://issues.apache.org/jira/browse/LOG4J2-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117178#comment-15117178
]
Philipp Knobel commented on LOG4J2-601:
---------------------------------------
As the Filter of a Logger is actually influencing if the Logger is going to
accept the message or not, it should probably be evaluated, too. But I see a
potential issues:
The Filter might decide to log or not to log, based on data available only
during the actual log invocation (like LogEvent). The decision the filter is
coming up with, during isEnabled vs. log() might be different, causing that
messages which should be logged won't pass isEnabled and vice versa. A new
filter method which is explicitly meant for evaluating isEnabled methods might
be handy here, where filter which don't rely on logEvent will decide.
But now that I think about it, skipping this kind of filters ,might actually
raise another issue. Let's assume that there's composite filter in play, where
the first filter relies on logEvent and the second doesn't. Now it can happen
that the first filter will be neutral and the second one denies. Although the
real log() call would have caused the first filter to ACCEPT. That would render
the whole isEnabled check totally unreliable.
> Log.log and isEnabled react differently for marker filters
> ----------------------------------------------------------
>
> Key: LOG4J2-601
> URL: https://issues.apache.org/jira/browse/LOG4J2-601
> Project: Log4j 2
> Issue Type: Bug
> Components: Filters
> Affects Versions: 2.0-rc1
> Environment: OSX 10.8/10.9, Eclipse, Java 1.6/1.7
> Reporter: Dan Hagberg
> Attachments: DbMarkers.java, TestLog2.java,
> console_atConfigLevel.txt, console_atLoggerLevel.txt, console_noFilter.txt,
> log4j2_atConfigLevel.xml, log4j2_atLoggerLevel.xml, log4j2_nofilter.xml
>
>
> I am trying to determine if a logger exists for a Marker in Log4j 2. The
> filter works when actually logging. The problem is when checking
> isEnabled(level, marker). If the MarkerFilters are at the Configuration
> level, then it works as expected. If at the logger or appender level, then it
> bypasses the marker and considers only the threshold level.
> Looking at the documentation, it looks like if accepted/denied is at the
> configuration level, then it will not check any other filters and that status
> will be honored, so that makes sense that it works here.
> Is this the expected behavior that the isEnabled works only at the
> configuration level and is not expected to represent whether or not a message
> will be logged? Or is it that if isEnabled returns true, then the message
> should be logged?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
