[JIRA] Created: (LBCORE-118) EvaluatorFilter returns OnMatch when marker is null
EvaluatorFilter returns OnMatch when marker is null --------------------------------------------------- Key: LBCORE-118 URL: http://jira.qos.ch/browse/LBCORE-118 Project: logback-core Issue Type: Bug Components: Other Affects Versions: 0.9.17 Environment: Windows XP Reporter: Manuel Kueblboeck Assignee: Logback dev list Priority: Minor <appender name="Alert" class="ch.qos.logback.core.ConsoleAppender"> <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> <evaluator name="isAlert"> <expression>marker.getName().equals("Alert")</expression> </evaluator> <OnMatch>ACCEPT</OnMatch> <OnMismatch>DENY</OnMismatch> </filter> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>ALERT: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</Pattern> </layout> </appender> In the above example, when an event is logged without an attached marker, the filter returns OnMatch. I would expect that it returns OnMismatch. A work around for this issue is to change the expression to this: <expression>marker != null && marker.getName().equals("Alert")</expression> -- 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
[ http://jira.qos.ch/browse/LBCORE-118?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu commented on LBCORE-118: ----------------------------------- When the marker is null, during the evaluation of the boolean expression a NullPointerException is thrown. This exception is added into the internal list of status messages. Moreover, since the result of the evaluation is undetermined (an exception was thrown), neither OnMatch nor OnMismatch properties apply and the EvaluatorFilter returns NEUTRAL, as it should. One way to fix this issue, is to modify the evaluator expression to "marker != null && marker.getName().equals("Alert")". I am hesitating to modify JaninoEventEvaluator to inject a dummy marker in case the logging event's marker is null. This would solve the issue you are facing.
EvaluatorFilter returns OnMatch when marker is null ---------------------------------------------------
Key: LBCORE-118 URL: http://jira.qos.ch/browse/LBCORE-118 Project: logback-core Issue Type: Bug Components: Other Affects Versions: 0.9.17 Environment: Windows XP Reporter: Manuel Kueblboeck Assignee: Ceki Gulcu Priority: Minor
<appender name="Alert" class="ch.qos.logback.core.ConsoleAppender"> <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> <evaluator name="isAlert"> <expression>marker.getName().equals("Alert")</expression> </evaluator> <OnMatch>ACCEPT</OnMatch> <OnMismatch>DENY</OnMismatch> </filter> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>ALERT: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</Pattern> </layout> </appender> In the above example, when an event is logged without an attached marker, the filter returns OnMatch. I would expect that it returns OnMismatch. A work around for this issue is to change the expression to this: <expression>marker != null && marker.getName().equals("Alert")</expression>
-- 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
[ http://jira.qos.ch/browse/LBCORE-118?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu edited comment on LBCORE-118 at 11/10/09 9:12 PM: ------------------------------------------------------------- When the marker is null, during the evaluation of the boolean expression a NullPointerException is thrown. This exception is added into the internal list of status messages. Moreover, since the result of the evaluation is undetermined (an exception was thrown), neither OnMatch nor OnMismatch properties apply and the EvaluatorFilter returns NEUTRAL, as it should. One way to fix this issue, is to modify the evaluator expression to "marker != null && marker.getName().equals("Alert")". I am hesitating to modify JaninoEventEvaluator to inject a dummy marker in case the logging event's marker is null. This would solve the issue you are facing. However, there is a downside. Users who would expect to find a null marker will see a dummy marker and might get confused. was (Author: noreply.ceki@qos.ch): When the marker is null, during the evaluation of the boolean expression a NullPointerException is thrown. This exception is added into the internal list of status messages. Moreover, since the result of the evaluation is undetermined (an exception was thrown), neither OnMatch nor OnMismatch properties apply and the EvaluatorFilter returns NEUTRAL, as it should. One way to fix this issue, is to modify the evaluator expression to "marker != null && marker.getName().equals("Alert")". I am hesitating to modify JaninoEventEvaluator to inject a dummy marker in case the logging event's marker is null. This would solve the issue you are facing.
EvaluatorFilter returns OnMatch when marker is null ---------------------------------------------------
Key: LBCORE-118 URL: http://jira.qos.ch/browse/LBCORE-118 Project: logback-core Issue Type: Bug Components: Other Affects Versions: 0.9.17 Environment: Windows XP Reporter: Manuel Kueblboeck Assignee: Ceki Gulcu Priority: Minor
<appender name="Alert" class="ch.qos.logback.core.ConsoleAppender"> <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> <evaluator name="isAlert"> <expression>marker.getName().equals("Alert")</expression> </evaluator> <OnMatch>ACCEPT</OnMatch> <OnMismatch>DENY</OnMismatch> </filter> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>ALERT: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</Pattern> </layout> </appender> In the above example, when an event is logged without an attached marker, the filter returns OnMatch. I would expect that it returns OnMismatch. A work around for this issue is to change the expression to this: <expression>marker != null && marker.getName().equals("Alert")</expression>
-- 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
[ http://jira.qos.ch/browse/LBCORE-118?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu resolved LBCORE-118. ------------------------------- Resolution: Won't Fix The present behavior is deemed correct. Nevertheless, the documentation has been modified mentioning that the "marker" variable can be null and that it is the user's responsibility to check for this condition in order to avoid NullPointerExceptions,
EvaluatorFilter returns OnMatch when marker is null ---------------------------------------------------
Key: LBCORE-118 URL: http://jira.qos.ch/browse/LBCORE-118 Project: logback-core Issue Type: Bug Components: Other Affects Versions: 0.9.17 Environment: Windows XP Reporter: Manuel Kueblboeck Assignee: Ceki Gulcu Priority: Minor
<appender name="Alert" class="ch.qos.logback.core.ConsoleAppender"> <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> <evaluator name="isAlert"> <expression>marker.getName().equals("Alert")</expression> </evaluator> <OnMatch>ACCEPT</OnMatch> <OnMismatch>DENY</OnMismatch> </filter> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>ALERT: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</Pattern> </layout> </appender> In the above example, when an event is logged without an attached marker, the filter returns OnMatch. I would expect that it returns OnMismatch. A work around for this issue is to change the expression to this: <expression>marker != null && marker.getName().equals("Alert")</expression>
-- 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
participants (2)
-
Ceki Gulcu (JIRA) -
Manuel Kueblboeck (JIRA)