[LOG4J2-3534] Fix LevelRangeFilterBuilder to align with log4j1's behavior #924
Conversation
log4j-1.2-api/src/test/java/org/apache/log4j/config/PropertiesConfigurationTest.java
Show resolved
Hide resolved
yueki1993
force-pushed
the
fix-level-range-filter-builder
branch
from
965b337 to
3981d69
Compare
This reverts commit c57d611.
log4j-1.2-api/src/test/java/org/apache/log4j/config/PropertiesConfigurationTest.java
Outdated
Show resolved
Hide resolved
| org.apache.logging.log4j.core.Filter.Result onMatch = acceptOnMatch | ||
| ? org.apache.logging.log4j.core.Filter.Result.ACCEPT | ||
| : org.apache.logging.log4j.core.Filter.Result.NEUTRAL; | ||
|
|
There was a problem hiding this comment.
Is it better to output warning log if max < min here?
Current released implementation should work if we swap levelMin and levelMax in log4j.properties.
This is degradation for people who configure log4j like that.
There was a problem hiding this comment.
There was no warning in Log4j 1.x, so I wouldn't add it here. You can add a warning in the Log4j2 factory LevelRangeFilter#createFilter (using the StatusLogger).
There was a problem hiding this comment.
OK, I won't add warning log in Log4j2 factory too because if someone misconfigures LogLevelRangeFilter, no logs will be output - they should be able to notice misconfiguration easily.
|
Hello @ppkarwasz, |
|
@yueki1993, |
…vior (apache#924) The current `LevelRangeFilterBuilder` does not take into account the inversion of the level scale between Log4j 1 and Log4j 2: a minimal Log4j 1 level corresponds to a maximal Log4j 2 level and vice versa.
…vior (apache#924) The current `LevelRangeFilterBuilder` does not take into account the inversion of the level scale between Log4j 1 and Log4j 2: a minimal Log4j 1 level corresponds to a maximal Log4j 2 level and vice versa.
…vior (apache#924) The current `LevelRangeFilterBuilder` does not take into account the inversion of the level scale between Log4j 1 and Log4j 2: a minimal Log4j 1 level corresponds to a maximal Log4j 2 level and vice versa.
2 participants
https://issues.apache.org/jira/browse/LOG4J2-3534