November 2009 - logback-dev

[JIRA] Created: (LBCLASSIC-155) ThrowableProxy passed into EventEvaluator
by Hontvári József (JIRA) 10 Nov '09

10 Nov '09

ThrowableProxy passed into EventEvaluator ----------------------------------------- Key: LBCLASSIC-155 URL: http://jira.qos.ch/browse/LBCLASSIC-155 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.917 Reporter: Hontvári József Assignee: Logback dev list In an event evaluator which is called in the option part of an "ex" formatting specifier I cannot use a "throwable instanceof example" expression, because the evaluator receives a ThrowableProxy and not a Throwable. Here is a stack trace, dumped from the evaluator expression. It does include a ThrowableProxyConverter.convert call: java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1206) at mireka.E.f(E.java:21) at SC.eval0(SC.java:3) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.janino.ScriptEvaluator.evaluate(ScriptEvaluator.java) at org.codehaus.janino.ScriptEvaluator.evaluate(ScriptEvaluator.java) at ch.qos.logback.core.boolex.JaninoEventEvaluatorBase.evaluat (JaninoEventEvaluatorBase.java:53) at ch.qos.logback.classic.pattern.ThrowableProxyConverter.convert(ThrowableProxyConverter.java:109) at ch.qos.logback.classic.pattern.ThrowableProxyConverter.convert(ThrowableProxyConverter.java:31) at ch.qos.logback.core.pattern.FormattingConverter.write(FormattingConverter.java:32) at ch.qos.logback.core.pattern.PatternLayoutBase.writeLoopOnConverters(PatternLayoutBase.java:110) at ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:132) at ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:51) at ch.qos.logback.core.WriterAppender.subAppend(WriterAppender.java:267) at ch.qos.logback.core.WriterAppender.append(WriterAppender.java:117) at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:89) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:60) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:271) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:258) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:440) at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:394) at ch.qos.logback.classic.Logger.debug(Logger.java:517) at org.subethamail.smtp.server.Session.run(Session.java:119) -- 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

2 1

branch, master, updated. 2f865c2f17e2444e562781b250950d29e3f429f8
by git-noreply＠pixie.qos.ch 10 Nov '09

10 Nov '09

The branch, master has been updated via 2f865c2f17e2444e562781b250950d29e3f429f8 (commit) from d6158815139bdc475619c07ce2a1e21185942343 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=2f865c2f17e2444e562781b2… http://github.com/ceki/logback/commit/2f865c2f17e2444e562781b250950d29e3f42… commit 2f865c2f17e2444e562781b250950d29e3f429f8 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Tue Nov 10 18:44:10 2009 +0100 minor edit diff --git a/logback-site/src/site/pages/manual/filters.html b/logback-site/src/site/pages/manual/filters.html index 7ab56f7..3b61138 100644 --- a/logback-site/src/site/pages/manual/filters.html +++ b/logback-site/src/site/pages/manual/filters.html @@ -488,16 +488,15 @@ java chapter6.FilterEvents src/main/java/chapter6/basicConfiguration.xml <h2><a name="matcher" href="#matcher">Matchers</a></h2> - While it is possible to do pattern matching operations by - invoking the <a + While it is possible to do pattern matching by invoking the <a href="http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html#matches%28jav…">matches()</a> method in the <code>String</code> class, this incurs the cost of - the creation by compilation of a new Pattern object each time the + compiling of a brand new <code>Pattern</code> object each time the filter is invoked. To eliminate this overhead, you can predefine one or more <a href="../xref/ch/qos/logback/core/boolex/Matcher.html">Matcher</a> - objects. Once a matcher is defined, it can be repeatedly referenced - by name in the evaluator expression. + objects. Once a matcher is defined, it can be repeatedly + referenced by name in the evaluator expression. An example should clarify the point: @@ -539,6 +538,13 @@ java chapter6.FilterEvents src/main/java/chapter6/basicConfiguration.xml 223 [main] INFO chapter6.FilterEvents - logging statement 4 225 [main] INFO chapter6.FilterEvents - logging statement 8 + In case you need to define additional matchers, you can do so by + adding further <code><matcher></code> elements. + +  +  +  + <h2><a name="TurboFilter" href="#TurboFilter">TurboFilters</a></h2> <code>TurboFilter</code> objects all extend the ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/manual/filters.html | 16 +++++++++++----- 1 files changed, 11 insertions(+), 5 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

branch, master, updated. d6158815139bdc475619c07ce2a1e21185942343
by git-noreply＠pixie.qos.ch 10 Nov '09

10 Nov '09

The branch, master has been updated via d6158815139bdc475619c07ce2a1e21185942343 (commit) from 40c50961a8e1685a2d7dc1bad65eea2361b5c740 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=d6158815139bdc475619c07c… http://github.com/ceki/logback/commit/d6158815139bdc475619c07ce2a1e21185942… commit d6158815139bdc475619c07ce2a1e21185942343 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Tue Nov 10 17:07:36 2009 +0100 - ongoing editing of filters.html - fixed http://jira.qos.ch/browse/LBCLASSIC-155 diff --git a/logback-classic/src/main/java/ch/qos/logback/classic/boolex/JaninoEventEvaluator.java b/logback-classic/src/main/java/ch/qos/logback/classic/boolex/JaninoEventEvaluator.java index 093cc8e..232c689 100644 --- a/logback-classic/src/main/java/ch/qos/logback/classic/boolex/JaninoEventEvaluator.java +++ b/logback-classic/src/main/java/ch/qos/logback/classic/boolex/JaninoEventEvaluator.java @@ -23,6 +23,7 @@ import ch.qos.logback.classic.Level; import ch.qos.logback.classic.spi.ILoggingEvent; import ch.qos.logback.classic.spi.IThrowableProxy; import ch.qos.logback.classic.spi.LoggerContextVO; +import ch.qos.logback.classic.spi.ThrowableProxy; import ch.qos.logback.core.CoreConstants; import ch.qos.logback.core.boolex.JaninoEventEvaluatorBase; import ch.qos.logback.core.boolex.Matcher; @@ -45,12 +46,15 @@ public class JaninoEventEvaluator extends JaninoEventEvaluatorBase<ILoggingEvent DEFAULT_PARAM_NAME_LIST.add("event"); DEFAULT_PARAM_NAME_LIST.add("message"); + + DEFAULT_PARAM_NAME_LIST.add("formattedMessage"); DEFAULT_PARAM_NAME_LIST.add("logger"); DEFAULT_PARAM_NAME_LIST.add("loggerContext"); DEFAULT_PARAM_NAME_LIST.add("level"); DEFAULT_PARAM_NAME_LIST.add("timeStamp"); DEFAULT_PARAM_NAME_LIST.add("marker"); DEFAULT_PARAM_NAME_LIST.add("mdc"); + DEFAULT_PARAM_NAME_LIST.add("throwableProxy"); DEFAULT_PARAM_NAME_LIST.add("throwable"); DEFAULT_PARAM_TYPE_LIST.add(int.class); @@ -61,12 +65,14 @@ public class JaninoEventEvaluator extends JaninoEventEvaluatorBase<ILoggingEvent DEFAULT_PARAM_TYPE_LIST.add(ILoggingEvent.class); DEFAULT_PARAM_TYPE_LIST.add(String.class); DEFAULT_PARAM_TYPE_LIST.add(String.class); + DEFAULT_PARAM_TYPE_LIST.add(String.class); DEFAULT_PARAM_TYPE_LIST.add(LoggerContextVO.class); DEFAULT_PARAM_TYPE_LIST.add(int.class); DEFAULT_PARAM_TYPE_LIST.add(long.class); DEFAULT_PARAM_TYPE_LIST.add(Marker.class); DEFAULT_PARAM_TYPE_LIST.add(Map.class); DEFAULT_PARAM_TYPE_LIST.add(IThrowableProxy.class); + DEFAULT_PARAM_TYPE_LIST.add(Throwable.class); } @@ -111,18 +117,29 @@ public class JaninoEventEvaluator extends JaninoEventEvaluatorBase<ILoggingEvent values[i++] = loggingEvent; values[i++] = loggingEvent.getMessage(); + values[i++] = loggingEvent.getFormattedMessage(); values[i++] = loggingEvent.getLoggerName(); values[i++] = loggingEvent.getLoggerContextVO(); values[i++] = loggingEvent.getLevel().toInteger(); values[i++] = new Long(loggingEvent.getTimeStamp()); values[i++] = loggingEvent.getMarker(); values[i++] = loggingEvent.getMDCPropertyMap(); - if (loggingEvent.getThrowableProxy() != null) { - values[i++] = loggingEvent.getThrowableProxy(); + + IThrowableProxy iThrowableProxy = loggingEvent.getThrowableProxy(); + + if (iThrowableProxy != null) { + values[i++] = iThrowableProxy; + if(iThrowableProxy instanceof ThrowableProxy) { + values[i++] = ((ThrowableProxy) iThrowableProxy).getThrowable(); + } else { + values[i++] = null; + } } else { values[i++] = null; + values[i++] = null; } + for(int j = 0; j < matcherListSize; j++) { values[i++] = (Matcher) matcherList.get(j); } diff --git a/logback-classic/src/main/java/ch/qos/logback/classic/joran/action/EvaluatorAction.java b/logback-classic/src/main/java/ch/qos/logback/classic/joran/action/EvaluatorAction.java index 3d2c890..3880d08 100644 --- a/logback-classic/src/main/java/ch/qos/logback/classic/joran/action/EvaluatorAction.java +++ b/logback-classic/src/main/java/ch/qos/logback/classic/joran/action/EvaluatorAction.java @@ -16,11 +16,8 @@ package ch.qos.logback.classic.joran.action; import ch.qos.logback.classic.boolex.JaninoEventEvaluator; import ch.qos.logback.core.joran.action.AbstractEventEvaluatorAction; - public class EvaluatorAction extends AbstractEventEvaluatorAction { - - protected String defaultClassName() { + protected String defaultClassName() { return JaninoEventEvaluator.class.getName(); } - } diff --git a/logback-classic/src/main/java/ch/qos/logback/classic/spi/LoggerContextVO.java b/logback-classic/src/main/java/ch/qos/logback/classic/spi/LoggerContextVO.java index b7768d8..e6cbe18 100644 --- a/logback-classic/src/main/java/ch/qos/logback/classic/spi/LoggerContextVO.java +++ b/logback-classic/src/main/java/ch/qos/logback/classic/spi/LoggerContextVO.java @@ -20,13 +20,14 @@ import ch.qos.logback.classic.LoggerContext; /** * LoggerContextVO offers a restricted view of LoggerContext intended to be - * exposed by LoggingEvent to remote system. This restricted view is optimized + * exposed by LoggingEvent to remote systems. This restricted view is optimized * for serialization. * - * Some of the LoggerContext or Logger attributes should not survive + * + * Some of the LoggerContext or Logger attributes MUST not survive * serialization, e.g appenders, level values etc, as these attributes may have - * other values on the remote platform. LoggerContextVO class exposes - * the minimal (relevant) attributes to remote host, instead of having to deal + * other values on the remote platform. LoggerContextVO class exposes the + * minimal and relevant attributes to the remote host, instead of having to deal * with an incomplete LoggerContext with many null references. * * @author Ceki Gülcü diff --git a/logback-classic/src/test/java/ch/qos/logback/classic/boolex/JaninoEventEvaluatorTest.java b/logback-classic/src/test/java/ch/qos/logback/classic/boolex/JaninoEventEvaluatorTest.java index 13e8ecf..8be5a62 100644 --- a/logback-classic/src/test/java/ch/qos/logback/classic/boolex/JaninoEventEvaluatorTest.java +++ b/logback-classic/src/test/java/ch/qos/logback/classic/boolex/JaninoEventEvaluatorTest.java @@ -17,6 +17,8 @@ import static org.junit.Assert.assertFalse; import static org.junit.Assert.assertTrue; import static org.junit.Assert.fail; +import java.io.IOException; + import org.junit.Test; import org.slf4j.MarkerFactory; @@ -249,4 +251,27 @@ public class JaninoEventEvaluatorTest { loop(jee, "x.matches(message): "); } + @Test + public void throwable_LBCLASSIC_155_I() throws EvaluationException { + JaninoEventEvaluator jee = new JaninoEventEvaluator(); + jee.setExpression("throwable instanceof java.io.IOException"); + jee.setContext(loggerContext); + jee.start(); + + LoggingEvent event = makeLoggingEvent(new IOException("")); + assertTrue(jee.evaluate(event)); + } + + + @Test + public void throwable_LBCLASSIC_155_II() throws EvaluationException { + JaninoEventEvaluator jee = new JaninoEventEvaluator(); + jee.setExpression("throwableProxy.getClassName().contains(\"IO\")"); + jee.setContext(loggerContext); + jee.start(); + + LoggingEvent event = makeLoggingEvent(new IOException("")); + assertTrue(jee.evaluate(event)); + } + } diff --git a/logback-core/src/main/java/ch/qos/logback/core/boolex/EventEvaluatorBase.java b/logback-core/src/main/java/ch/qos/logback/core/boolex/EventEvaluatorBase.java index 69c60a5..6b758cc 100644 --- a/logback-core/src/main/java/ch/qos/logback/core/boolex/EventEvaluatorBase.java +++ b/logback-core/src/main/java/ch/qos/logback/core/boolex/EventEvaluatorBase.java @@ -39,7 +39,6 @@ abstract public class EventEvaluatorBase<E> extends ContextAwareBase implements public void start() { started = true; - } public void stop() { diff --git a/logback-examples/src/main/java/chapter6/basicEventEvaluator.xml b/logback-examples/src/main/java/chapter6/basicEventEvaluator.xml index 16ceb8a..f6a1e3e 100644 --- a/logback-examples/src/main/java/chapter6/basicEventEvaluator.xml +++ b/logback-examples/src/main/java/chapter6/basicEventEvaluator.xml @@ -2,7 +2,7 @@ <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> - <evaluator name="myEval"> + <evaluator> <expression>message.contains("billing")</expression> </evaluator> <OnMismatch>NEUTRAL</OnMismatch> diff --git a/logback-examples/src/main/java/chapter6/basicEventEvaluator.xml b/logback-examples/src/main/java/chapter6/evaluatorWithMatcher.xml similarity index 62% copy from logback-examples/src/main/java/chapter6/basicEventEvaluator.xml copy to logback-examples/src/main/java/chapter6/evaluatorWithMatcher.xml index 16ceb8a..64d0efb 100644 --- a/logback-examples/src/main/java/chapter6/basicEventEvaluator.xml +++ b/logback-examples/src/main/java/chapter6/evaluatorWithMatcher.xml @@ -2,8 +2,14 @@ <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> - <evaluator name="myEval"> - <expression>message.contains("billing")</expression> + <evaluator> + + <matcher> + <Name>odd</Name> + <regex>statement [13579]</regex> + </matcher> + + <expression>message.contains("billing") || odd.matches(formattedMessage)</expression> </evaluator> <OnMismatch>NEUTRAL</OnMismatch> <OnMatch>DENY</OnMatch> diff --git a/logback-site/src/site/pages/manual/filters.html b/logback-site/src/site/pages/manual/filters.html index 871ef11..7ab56f7 100644 --- a/logback-site/src/site/pages/manual/filters.html +++ b/logback-site/src/site/pages/manual/filters.html @@ -105,7 +105,7 @@ events, the value NEUTRAL is returned. -Example 6.1: Basic custom filter (<a href="../xref/chapter6/SampleFilter.html">logback-examples/src/main/java/chapter6/SampleFilter.java</a>) +Example 6.: Basic custom filter (<a href="../xref/chapter6/SampleFilter.html">logback-examples/src/main/java/chapter6/SampleFilter.java</a>) <pre class="prettyprint source">package chapter6; import ch.qos.logback.classic.spi.ILoggingEvent; @@ -128,7 +128,7 @@ public class SampleFilter extends Filter>ILoggingEvent> { <code>SampleFilter</code> to a <code>ConsoleAppener</code>. -Example 6.2: SampleFilter configuration (logback-examples/src/main/java/chapter6/SampleFilterConfig.xml) +Example 6.: SampleFilter configuration (logback-examples/src/main/java/chapter6/SampleFilterConfig.xml) <pre class="prettyprint source"><configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> @@ -183,7 +183,7 @@ public class SampleFilter extends Filter>ILoggingEvent> { configuration file. -Example 6.3: Sample LevelFilter configuration (logback-examples/src/main/java/chapter6/levelFilterConfig.xml) +Example 6.: Sample LevelFilter configuration (logback-examples/src/main/java/chapter6/levelFilterConfig.xml) <pre class="prettyprint source"><configuration> <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> @@ -215,7 +215,7 @@ public class SampleFilter extends Filter>ILoggingEvent> { configuration file. -Example 6.4: Sample ThresholdFilter configuration (logback-examples/src/main/java/chapter6/thresholdFilterConfig.xml) +Example 6.: Sample ThresholdFilter configuration (logback-examples/src/main/java/chapter6/thresholdFilterConfig.xml) <pre class="prettyprint source"><configuration> <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> @@ -249,28 +249,29 @@ public class SampleFilter extends Filter>ILoggingEvent> { class="option">OnMismatch properties. - The <code>EventEvaluator</code> class is abstract and you can - implement your own even evaluation logic. Logback-classic ships + The <code>EventEvaluator</code> is an abstract class and you + can implement your own event evaluation logic by sub-classing + <code>EventEvaluator</code>. However, logback-classic also ships with a concrete evaluator implementation called <a href="../xref/ch/qos/logback/classic/boolex/JaninoEventEvaluator.html">JaninoEventEvaluator</a> - which takes artibtrary boolean expressions (in the Java language) - as the evaluation criispteria. We refer to such artbitrary boolean - expressions in the Java language as "evaulation - expressions". Evaluation expressions enable hereto - unprecedented flexibility in event filtering. + which takes artibtrary java language boolean expressions as the + evaluation criteria. We refer to such java language boolean + expressions as "evaulation expressions". Evaluation + expressions enable hereto unprecedented flexibility in event + filtering. Evaluation expressions are compiled on-the-fly during the interpretation of the configuration file. As a user, you do not need to worry about the actual plumbing. However, it is your - reponsibility to ensure that the expression is boolean, that it - evaluates to true or false. + reponsibility to ensure that the java-language expression is + boolean, that it evaluates to true or false. Given that an evaluation expression acts on the current logging - event, logback implicitly exposes various fields of the logging + event, logback automatically exports various fields of the logging event as variables accessible from the evaluation expression. The - list of these implicit variables is given below. + case-sensitive names these variables is listed below. <table class="bodyTable"> @@ -294,19 +295,37 @@ public class SampleFilter extends Filter>ILoggingEvent> { <tr class="alt"> <td>message</td> <td><code>String</code></td> - <td>The message of the logging request.</td> + <td>The raw message of the logging request. For some logger + l, when you write l.info("Hello {}", name); where + name is assigned the value "Alice", then "Hello {}" is the + message.</td> </tr> + + <tr> + <td>formatedMessage</td> + <td><code>String</code></td> + <td>The formatted message in the logging request. For some + logger l, when you write l.info("Hello {}", name); + where name is assigned the value "Alice", then "Hello Alice" + is the formatted message.</td> </tr> - <tr> + + <tr class="alt"> <td>logger</td> - <td><code>LoggerRemoteView</code></td> - <td>This object is a proxy for the logger object where the - logging request was issued. It can be viewed as a regular - logger object. However, it has some nice performance - properties, especially with respect to serialization. + <td><code>String</code></td> + <td>The name of the logger. + </td> + </tr> + + <tr> + <td>loggerContext</td> + <td><a + href="../xref/ch/qos/logback/classic/spi/LoggerContextVO.html"><code>LoggerContextVO</code></a></td> + <td>A restricted (value object) view of the logger context to which the logging event belongs to. </td> </tr> - <tr class="alt"> + + <tr class="alt"> <td>level</td> <td><code>int</code></td> <td>The int value corresponding to the level. To help create @@ -316,6 +335,7 @@ public class SampleFilter extends Filter>ILoggingEvent> { INFO is a correct expression. </td> </tr> + <tr> <td>timeStamp </td> @@ -324,7 +344,7 @@ public class SampleFilter extends Filter>ILoggingEvent> { creation. </td> </tr> - <tr class="alt"> + <tr class="alt"> <td>marker</td> <td><code>Marker</code></td> <td>The <code>Marker</code> object associated with the logging @@ -332,39 +352,53 @@ public class SampleFilter extends Filter>ILoggingEvent> { </td> </tr> <tr> - <td>mdc - </td> + <td>mdc</td> <td><code>Map</code></td> <td>A map containing all the MDC values at the time of the creation of the logging event. A value can be accessed by using the following expression: mdc.get("myKey"). </td> </tr> - <tr class="alt"> + + <tr class="alt"> <td>throwable</td> - <td><code>Throwable</code></td> - <td>The exception associated with the logging event + <td>java.lang.Throwable</td> + <td>If no exception is associated with the event, then the + value of the "throwable" variable will be null. Unfortunately, + "throwable" does not survive serialization. Thus, on remote + systems, its value will always be null. For location + independent expresisons, use the <code>throwableProxy</code> + variable described next. + </td> + </tr> + + <tr> + <td>throwableProxy</td> + <td><a + href="../xref/ch/qos/logback/classic/spi/IThrowableProxy.html"><code>IThrowableProxy</code></a></td> + <td>A proxy for the exception associated with the logging + event. If no exception is associated with the event, then the + value of the "throwableProxy" variable will be null. In + contrast to "throwable", when an exception is associated with + an event, the value of "throwableProxy" will be non-null even + on remote systems, that is even after serialization. </td> </tr> - </table> - - The behaviour of the <code>EvaluatorFilter</code> is also - affected by its OnMatch and OnMismatch options taking values of type - <code>FilterReply</code>, i.e. DENY, ACCEPT, NEUTRAL. - + + </table> + Here is a concrete example. -Example 6.5: Basic event evaluator usage (logback-examples/src/main/java/chapter6/basicEventEvaluator.xml) +Example 6.: Basic event evaluator usage (logback-examples/src/main/java/chapter6/basicEventEvaluator.xml) -<pre class="prettyprint source"><configuration> +<pre class="prettyprint source longline"><configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> - <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> - <evaluator name="myEval"> + <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> + <evaluator>  <expression>message.contains("billing")</expression> </evaluator> <OnMismatch>NEUTRAL</OnMismatch> @@ -382,18 +416,29 @@ public class SampleFilter extends Filter>ILoggingEvent> { </root> </configuration></pre> - The bold part in the previous configuration adds an + The bold part in the above configuration file adds an <code>EvaluatorFilter</code> to a <code>ConsoleAppender</code>. An - <code>EventEvaluator</code> is then injected into the - <code>EvaluatorFilter</code>. The expression element - corresponds to the evaluation expression described previously. The - expression <code>message.contains("billing")</code> returns a - boolean value. Notice that the message variable is - defined implicitly. + evaluator of type <code>JaninoEventEvaluator</code> is then + injected into the <code>EvaluatorFilter</code>. In the absence of + class attribute in the + <code><evaluator></code> element specified by the user, joran + will infer a default type, i.e. <code>JaninoEventEvaluator</code>, + for the evaluator. This is one of the <a + href="onJoran.html#defaultClassMapping">few occurrences</a> where + Joran implicitly infers the type of a component. + + + The expression element corresponds to the evaluation + expression just discussed. The expression + <code>message.contains("billing")</code> returns a boolean + value. Notice that the message variable is exported + automatically by <code>JaninoEventEvaluator</code>. - This evalutor filter will drop all logging events whose message - contains the string "billing". + Given that the OnMatch property is + set to NEUTRAL and the OnMismatch + property set to DENY, this evalutor filter will drop all logging + events whose message contains the string "billing". The <a @@ -421,11 +466,12 @@ java chapter6.FilterEvents src/main/java/chapter6/basicConfiguration.xml - Suppose that we want to get rid of the billing information. - The basicEventEvaluator.xml configuration file just - described, does exactly what we want. + Suppose that we want to get rid of the "billing statement". + The basicEventEvaluator.xml configuration file listed + above filters messages containing the string "billing" which is + precisely the desired outcome. - Running with filters: + Running with basicEventEvaluator.xml: java chapter6.FilterEvents src/main/java/chapter6/basicEventEvaluator.xml we obtain: @@ -440,7 +486,59 @@ java chapter6.FilterEvents src/main/java/chapter6/basicConfiguration.xml 0 [main] INFO chapter6.FilterEvents - logging statement 8 0 [main] INFO chapter6.FilterEvents - logging statement 9 + <h2><a name="matcher" href="#matcher">Matchers</a></h2> + + While it is possible to do pattern matching operations by + invoking the <a + href="http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html#matches%28jav…">matches()</a> + method in the <code>String</code> class, this incurs the cost of + the creation by compilation of a new Pattern object each time the + filter is invoked. To eliminate this overhead, you can predefine + one or more <a + href="../xref/ch/qos/logback/core/boolex/Matcher.html">Matcher</a> + objects. Once a matcher is defined, it can be repeatedly referenced + by name in the evaluator expression. + + An example should clarify the point: + +Example 6.: Defining matchers in an event evaluator (logback-examples/src/main/java/chapter6/evaluatorWithMatcher.xml) + + <pre class="prettyprint source longline"><configuration debug="true"> + + <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> + <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> + <evaluator> + <matcher> + <Name>odd</Name> +  + <regex>statement [13579]</regex> + </matcher> + + <expression>message.contains("billing") || odd.matches(formattedMessage)</expression> + </evaluator> + <OnMismatch>NEUTRAL</OnMismatch> + <OnMatch>DENY</OnMatch> + </filter> + <layout> + <pattern>%-4relative [%thread] %-5level %logger - %msg%n</pattern> + </layout> + </appender> + + <root level="DEBUG"> + <appender-ref ref="STDOUT" /> + </root> +</configuration></pre> + + Running with evaluatorWithMatcher.xml: + java chapter6.FilterEvents src/main/java/chapter6/evaluatorWithMatcher.xml + we obtain: + + 220 [main] INFO chapter6.FilterEvents - logging statement 0 +223 [main] INFO chapter6.FilterEvents - logging statement 2 +223 [main] INFO chapter6.FilterEvents - logging statement 4 +225 [main] INFO chapter6.FilterEvents - logging statement 8 + <h2><a name="TurboFilter" href="#TurboFilter">TurboFilters</a></h2> <code>TurboFilter</code> objects all extend the @@ -480,7 +578,7 @@ java chapter6.FilterEvents src/main/java/chapter6/basicConfiguration.xml slightly more complex filter: -Example 6.6: Basic custom <code>TurboFilter</code> (<a href="../xref/chapter6/SampleTurboFilter.html">logback-examples/src/main/java/chapter6/SampleTurboFilter.java</a>) +Example 6.: Basic custom <code>TurboFilter</code> (<a href="../xref/chapter6/SampleTurboFilter.html">logback-examples/src/main/java/chapter6/SampleTurboFilter.java</a>) <pre class="prettyprint source">package chapter6; import org.slf4j.Marker; @@ -545,7 +643,7 @@ public class SampleTurboFilter extends TurboFilter { created <code>TurboFilter</code>. -Example 6.7: Basic custom <code>TurboFilter</code> configuration (logback-examples/src/main/java/chapter6/sampleTurboFilterConfig.xml) +Example 6.: Basic custom <code>TurboFilter</code> configuration (logback-examples/src/main/java/chapter6/sampleTurboFilterConfig.xml) <pre class="prettyprint source"><configuration> <turboFilter class="chapter6.SampleTurboFilter"> <Marker>sample</Marker> @@ -581,7 +679,7 @@ public class SampleTurboFilter extends TurboFilter { <code>MDCFilter</code> and <code>MarkerFilter</code>. -Example 6.8: <code>MDCFilter</code> and <code>MarkerFilter</code> +Example 6.: <code>MDCFilter</code> and <code>MarkerFilter</code> configuration (logback-examples/src/main/java/chapter6/turboFilters.xml) <pre class="prettyprint source"><configuration> @@ -708,7 +806,7 @@ logger.debug("Hello {}.", name1);</pre> -Example: <code>DuplicateMessageFilter</code> +Example 6.: <code>DuplicateMessageFilter</code> configuration (logback-examples/src/main/java/chapter6/duplicateMessage.xml) <pre class="prettyprint source"><configuration> @@ -783,7 +881,7 @@ configuration (logback-examples/src/main/java/chapter6/duplicateMessage.xml) -Example 6.9: Access Evaluator (logback-examples/src/main/java/chapter6/accessEventEvaluator.xml) +Example 6.: Access Evaluator (logback-examples/src/main/java/chapter6/accessEventEvaluator.xml) <pre class="prettyprint source"><configuration> <appender name="STDOUT" diff --git a/logback-site/src/site/pages/manual/onJoran.html b/logback-site/src/site/pages/manual/onJoran.html index edabe34..ba08ea4 100644 --- a/logback-site/src/site/pages/manual/onJoran.html +++ b/logback-site/src/site/pages/manual/onJoran.html @@ -613,9 +613,12 @@ Element [abc] asked to be printed. </li> </ol> - In logback-classic, there are just two rules mapping (parent - class/property name) couples to a default class. These are listed in - the table below. + <h4><a name="defaultClassMapping" + href="#defaultClassMapping">Default class mapping</a></h4> + + In logback-classic, there are a handful of inernal rules mapping + parent class/property name couples to a default class. These are + listed in the table below. <table class="bodyTable"> <tr> @@ -623,12 +626,20 @@ Element [abc] asked to be printed. <th>property name </th> <th>default nested class</th> </tr> + <tr > <td>ch.qos.logback.core.AppenderBase</td> <td>layout</td> <td>ch.qos.logback.classic.PatternLayout</td> </tr> + <tr class="alt"> + <td>ch.qos.logback.core.UnsynchronizedAppenderBase</td> + <td>layout</td> + <td>ch.qos.logback.classic.PatternLayout</td> + </tr> + + <tr> <td>ch.qos.logback.core.filter.EvaluatorFilter</td> <td>evaluator</td> <td>ch.qos.logback.classic.boolex.JaninoEventEvaluator</td> diff --git a/logback-site/src/site/pages/news.html b/logback-site/src/site/pages/news.html index 2efe00d..5792c7e 100644 --- a/logback-site/src/site/pages/news.html +++ b/logback-site/src/site/pages/news.html @@ -36,6 +36,14 @@ by applying the relavant patch supplied by Hugues Malphettes. + JaninoEventEvaluator now passes the throwable associated with + an event as a <code>java.lang.Throwable</code> instead of an + <code>IThrowableProxy</code>. This fixes <a + href="http://jira.qos.ch/browse/LBCLASSIC-155">LBCLASSIC-155</a> + as reported by Hontvári József. See <a + href="manual/filters.html#evalutatorFilter">EvaluatorFilter + documentation</a> for more details. + <hr width="80%" align="center" /> <h3>9th of August 2009 - Release of version 0.9.17</h3> ----------------------------------------------------------------------- Summary of changes: .../classic/boolex/JaninoEventEvaluator.java | 21 ++- .../classic/joran/action/EvaluatorAction.java | 5 +- .../qos/logback/classic/spi/LoggerContextVO.java | 9 +- .../classic/boolex/JaninoEventEvaluatorTest.java | 25 +++ .../logback/core/boolex/EventEvaluatorBase.java | 1 - .../src/main/java/chapter6/basicEventEvaluator.xml | 2 +- ...EventEvaluator.xml => evaluatorWithMatcher.xml} | 10 +- logback-site/src/site/pages/manual/filters.html | 214 ++++++++++++++------ logback-site/src/site/pages/manual/onJoran.html | 17 ++- logback-site/src/site/pages/news.html | 8 + 10 files changed, 237 insertions(+), 75 deletions(-) copy logback-examples/src/main/java/chapter6/{basicEventEvaluator.xml => evaluatorWithMatcher.xml} (62%) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[JIRA] Created: (LBSITE-34) Document evaluator Matcher
by Ceki Gulcu (JIRA) 10 Nov '09

10 Nov '09

Document evaluator Matcher -------------------------- Key: LBSITE-34 URL: http://jira.qos.ch/browse/LBSITE-34 Project: logback-site Issue Type: Task Components: Documentation Affects Versions: 0.9.17 Reporter: Ceki Gulcu Assignee: Ceki Gulcu The Matcher functionality in evaluators is ill documented if at all. -- 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

1 1

branch, master, updated. 40c50961a8e1685a2d7dc1bad65eea2361b5c740
by git-noreply＠pixie.qos.ch 09 Nov '09

09 Nov '09

The branch, master has been updated via 40c50961a8e1685a2d7dc1bad65eea2361b5c740 (commit) from f8de3ee60aa6480630b97496b00d01fe49d958ae (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=40c50961a8e1685a2d7dc1ba… http://github.com/ceki/logback/commit/40c50961a8e1685a2d7dc1bad65eea2361b5c… commit 40c50961a8e1685a2d7dc1bad65eea2361b5c740 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Tue Nov 10 00:19:36 2009 +0100 ongoing editing diff --git a/logback-site/src/site/pages/manual/filters.html b/logback-site/src/site/pages/manual/filters.html index fcedf77..871ef11 100644 --- a/logback-site/src/site/pages/manual/filters.html +++ b/logback-site/src/site/pages/manual/filters.html @@ -267,12 +267,10 @@ public class SampleFilter extends Filter>ILoggingEvent> { evaluates to true or false. - Given that an evaluation expression is acts on the current - logging event, logback implicitly exposes various fields of a - logging event as variables accessible from the evaluation - expression. The list of these implicit variables is given - below. The scope of evaluation expressions is limited to the - logging event. + Given that an evaluation expression acts on the current logging + event, logback implicitly exposes various fields of the logging + event as variables accessible from the evaluation expression. The + list of these implicit variables is given below. <table class="bodyTable"> ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/manual/filters.html | 10 ++++------ 1 files changed, 4 insertions(+), 6 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

branch, master, updated. f8de3ee60aa6480630b97496b00d01fe49d958ae
by git-noreply＠pixie.qos.ch 09 Nov '09

09 Nov '09

The branch, master has been updated via f8de3ee60aa6480630b97496b00d01fe49d958ae (commit) from 87ab8377b3e25ac0accf5784f78a393bde865405 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=f8de3ee60aa6480630b97496… http://github.com/ceki/logback/commit/f8de3ee60aa6480630b97496b00d01fe49d95… commit f8de3ee60aa6480630b97496b00d01fe49d958ae Author: Ceki Gulcu <ceki(a)qos.ch> Date: Tue Nov 10 00:17:50 2009 +0100 - ongoing editing diff --git a/logback-site/src/site/pages/manual/filters.html b/logback-site/src/site/pages/manual/filters.html index 957ba15..fcedf77 100644 --- a/logback-site/src/site/pages/manual/filters.html +++ b/logback-site/src/site/pages/manual/filters.html @@ -252,34 +252,29 @@ public class SampleFilter extends Filter>ILoggingEvent> { The <code>EventEvaluator</code> class is abstract and you can implement your own even evaluation logic. Logback-classic ships with a concrete evaluator implementation called <a - href="../xref/ch/qos/logback/classic/boolex/JaninoEvaluator.html">JaninoEvaluator</a> - which take artibtrary java expressions as the evaluation criteria, - enabling unprecedented flexibility for filtering logging events. + href="../xref/ch/qos/logback/classic/boolex/JaninoEventEvaluator.html">JaninoEventEvaluator</a> + which takes artibtrary boolean expressions (in the Java language) + as the evaluation criispteria. We refer to such artbitrary boolean + expressions in the Java language as "evaulation + expressions". Evaluation expressions enable hereto + unprecedented flexibility in event filtering. - - A special category of filters is implemented by the <a - href="../xref/ch/qos/logback/core/filter/EvaluatorFilter.html"> - <code>EvaluatorFilter</code></a> class. These filters use an <a - href="../xref/ch/qos/logback/core/boolex/EventEvaluator.html"> - <code>EventEvaluator</code></a> object to decide whether to accept - or deny a request. This allows unprecedented flexibility in the - way that you can affect filtering of logging events. + + Evaluation expressions are compiled on-the-fly during the + interpretation of the configuration file. As a user, you do not + need to worry about the actual plumbing. However, it is your + reponsibility to ensure that the expression is boolean, that it + evaluates to true or false. + + + Given that an evaluation expression is acts on the current + logging event, logback implicitly exposes various fields of a + logging event as variables accessible from the evaluation + expression. The list of these implicit variables is given + below. The scope of evaluation expressions is limited to the + logging event. - As a user, you do not need to worry about the actual - plumbing. All you need to do is to give a name to the evaluator - and to specify an evaluation expression, that is a - boolean expression in regular Java syntax. These evaluation - expressions are compiled on-the-fly during the interpretation of - the configuration file. It is the users reponsibility to ensure - that the expression is boolean, that it evaluates to true or - false. In evaluation expressions, logback implicitly exposes - various fields of a logging event as variables. The list of these - implicit variables is given below. The scope of evaluation - expressions is limited to the logging event. - - - <table class="bodyTable"> <tr> <th>Name</th> ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/manual/filters.html | 45 ++++++++++------------- 1 files changed, 20 insertions(+), 25 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

branch, master, updated. 87ab8377b3e25ac0accf5784f78a393bde865405
by git-noreply＠pixie.qos.ch 09 Nov '09

09 Nov '09

The branch, master has been updated via 87ab8377b3e25ac0accf5784f78a393bde865405 (commit) from ef5a12d9162edc1cd94e5b71f4a58c3784e236be (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=87ab8377b3e25ac0accf5784… http://github.com/ceki/logback/commit/87ab8377b3e25ac0accf5784f78a393bde865… commit 87ab8377b3e25ac0accf5784f78a393bde865405 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Mon Nov 9 23:49:52 2009 +0100 - pom packaging instead of jar messes up copying of html files, rendering the site module useless. Reverting to jar packaging. diff --git a/logback-site/pom.xml b/logback-site/pom.xml index 3da1644..7f118ae 100644 --- a/logback-site/pom.xml +++ b/logback-site/pom.xml @@ -10,7 +10,7 @@ <groupId>ch.qos.logback</groupId> <artifactId>logback-site</artifactId> - <packaging>pom</packaging> + <packaging>jar</packaging> <version>${parent.version}</version> <name>Logback Site</name> ----------------------------------------------------------------------- Summary of changes: logback-site/pom.xml | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

branch, master, updated. ef5a12d9162edc1cd94e5b71f4a58c3784e236be
by git-noreply＠pixie.qos.ch 09 Nov '09

09 Nov '09

The branch, master has been updated via ef5a12d9162edc1cd94e5b71f4a58c3784e236be (commit) from 93098a6ca9cfb47dc87cd10e035d5f678723b1f5 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=ef5a12d9162edc1cd94e5b71… http://github.com/ceki/logback/commit/ef5a12d9162edc1cd94e5b71f4a58c3784e23… commit ef5a12d9162edc1cd94e5b71f4a58c3784e236be Author: Ceki Gulcu <ceki(a)qos.ch> Date: Mon Nov 9 22:43:04 2009 +0100 working on the filters.html chapter diff --git a/logback-classic/pom.xml b/logback-classic/pom.xml index 26beab2..a69ccb9 100644 --- a/logback-classic/pom.xml +++ b/logback-classic/pom.xml @@ -214,9 +214,7 @@ * </Import-Package> - <Bundle-RequiredExecutionEnvironment> - J2SE-1.5 - </Bundle-RequiredExecutionEnvironment> + <Bundle-RequiredExecutionEnvironment>J2SE-1.5</Bundle-RequiredExecutionEnvironment> </instructions> </configuration> </plugin> diff --git a/logback-classic/src/main/java/ch/qos/logback/classic/boolex/JaninoEventEvaluator.java b/logback-classic/src/main/java/ch/qos/logback/classic/boolex/JaninoEventEvaluator.java index c40b6db..093cc8e 100644 --- a/logback-classic/src/main/java/ch/qos/logback/classic/boolex/JaninoEventEvaluator.java +++ b/logback-classic/src/main/java/ch/qos/logback/classic/boolex/JaninoEventEvaluator.java @@ -52,7 +52,6 @@ public class JaninoEventEvaluator extends JaninoEventEvaluatorBase<ILoggingEvent DEFAULT_PARAM_NAME_LIST.add("marker"); DEFAULT_PARAM_NAME_LIST.add("mdc"); DEFAULT_PARAM_NAME_LIST.add("throwable"); - DEFAULT_PARAM_TYPE_LIST.add(int.class); DEFAULT_PARAM_TYPE_LIST.add(int.class); diff --git a/logback-classic/src/main/java/ch/qos/logback/classic/filter/LevelFilter.java b/logback-classic/src/main/java/ch/qos/logback/classic/filter/LevelFilter.java index 27db72b..336f13c 100644 --- a/logback-classic/src/main/java/ch/qos/logback/classic/filter/LevelFilter.java +++ b/logback-classic/src/main/java/ch/qos/logback/classic/filter/LevelFilter.java @@ -19,40 +19,36 @@ import ch.qos.logback.core.filter.AbstractMatcherFilter; import ch.qos.logback.core.spi.FilterReply; /** - * A class that filters events depending on their level. - * - * One can specify a level and the behaviour of the filter when - * said level is encountered in a logging event. - * - * For more information about filters, please refer to the online manual at - * http://logback.qos.ch/manual/filters.html + * A class that filters events by the level equality. + + * + * For more information about this filter, please refer to the online manual at + * http://logback.qos.ch/manual/filters.html#levelFilter * * @author Ceki Gülcü * @author Sébastien Pennec */ -public class LevelFilter extends AbstractMatcherFilter { +public class LevelFilter extends AbstractMatcherFilter<ILoggingEvent> { Level level; - + @Override - public FilterReply decide(Object eventObject) { + public FilterReply decide(ILoggingEvent event) { if (!isStarted()) { return FilterReply.NEUTRAL; } - - ILoggingEvent event = (ILoggingEvent)eventObject; - + if (event.getLevel().equals(level)) { return onMatch; } else { return onMismatch; } } - + public void setLevel(String level) { this.level = Level.toLevel(level); } - + public void start() { if (this.level != null) { super.start(); diff --git a/logback-classic/src/main/java/ch/qos/logback/classic/filter/ThresholdFilter.java b/logback-classic/src/main/java/ch/qos/logback/classic/filter/ThresholdFilter.java index 7ba9b8f..9bf1c2f 100644 --- a/logback-classic/src/main/java/ch/qos/logback/classic/filter/ThresholdFilter.java +++ b/logback-classic/src/main/java/ch/qos/logback/classic/filter/ThresholdFilter.java @@ -19,31 +19,29 @@ import ch.qos.logback.core.filter.Filter; import ch.qos.logback.core.spi.FilterReply; /** - * A class that filters events depending on their level. + * Filters events below the threshold level. * - * All events with a level under or above the specified - * level will be denied, while all events with a level + * Events with a level below the specified + * level will be denied, while events with a level * equal or above the specified level will trigger a * FilterReply.NEUTRAL result, to allow the rest of the * filter chain process the event. * * For more information about filters, please refer to the online manual at - * http://logback.qos.ch/manual/filters.html + * http://logback.qos.ch/manual/filters.html#thresholdFilter * * @author Sébastien Pennec */ -public class ThresholdFilter extends Filter { +public class ThresholdFilter extends Filter<ILoggingEvent> { Level level; @Override - public FilterReply decide(Object eventObject) { + public FilterReply decide(ILoggingEvent event) { if (!isStarted()) { return FilterReply.NEUTRAL; } - ILoggingEvent event = (ILoggingEvent)eventObject; - if (event.getLevel().isGreaterOrEqual(level)) { return FilterReply.NEUTRAL; } else { diff --git a/logback-classic/src/test/java/ch/qos/logback/classic/boolex/JaninoEventEvaluatorTest.java b/logback-classic/src/test/java/ch/qos/logback/classic/boolex/JaninoEventEvaluatorTest.java index 7d750f2..13e8ecf 100644 --- a/logback-classic/src/test/java/ch/qos/logback/classic/boolex/JaninoEventEvaluatorTest.java +++ b/logback-classic/src/test/java/ch/qos/logback/classic/boolex/JaninoEventEvaluatorTest.java @@ -113,6 +113,23 @@ public class JaninoEventEvaluatorTest { } @Test + public void testWithNullMarker_LBCORE_118() throws Exception { + JaninoEventEvaluator jee = new JaninoEventEvaluator(); + jee.setExpression("marker.contains(\"BLUE\")"); + jee.setContext(loggerContext); + jee.addMatcher(matcherX); + jee.start(); + + ILoggingEvent event = makeLoggingEvent(null); + try { + jee.evaluate(event); + fail("We should not reach this point"); + } catch (EvaluationException ee) { + + } + } + + @Test public void testWithNullMarker() throws Exception { JaninoEventEvaluator jee = new JaninoEventEvaluator(); jee.setExpression("marker.contains(\"BLUE\")"); @@ -129,6 +146,8 @@ public class JaninoEventEvaluatorTest { } } + + @Test public void testComplex() throws Exception { diff --git a/logback-core/src/main/java/ch/qos/logback/core/boolex/EventEvaluator.java b/logback-core/src/main/java/ch/qos/logback/core/boolex/EventEvaluator.java index 5c10720..28b14ac 100644 --- a/logback-core/src/main/java/ch/qos/logback/core/boolex/EventEvaluator.java +++ b/logback-core/src/main/java/ch/qos/logback/core/boolex/EventEvaluator.java @@ -17,36 +17,35 @@ import ch.qos.logback.core.spi.ContextAware; import ch.qos.logback.core.spi.LifeCycle; /** - * An EventEvaluator has the responsibility to evaluate whether a given an event - * matches a given criteria. + * Evaluates whether a given an event matches user-specified criteria. * - * Implementations are free to evaluate the event as they see fit. In + * + * Implementations are free to evaluate the event as they see fit. In * particular, the evaluation results may depend on previous events. - * + * * @author Ceki Gülcü */ public interface EventEvaluator<E> extends ContextAware, LifeCycle { - /** - * Evaluates whether the event passed as parameter matches this evaluator's - * matching criteria. + * Evaluates whether the event passed as parameter matches some user-specified + * criteria. * - * The <code>Evaluator</code> instance is free to evaluate the event as - * it pleases. In particular, the evaluation results may depend on - * previous events. + * + * The <code>Evaluator</code> is free to evaluate the event as it pleases. In + * particular, the evaluation results may depend on previous events. * - * @param event The event to evaluate - * @return true if there is a match, false otherwise. - * @throws NullPointerException can be thrown in presence of null values - * @throws EvaluationException Thrown during evaluation + * @param event + * The event to evaluate + * @return true if there is a match, false otherwise. + * @throws NullPointerException + * can be thrown in presence of null values + * @throws EvaluationException + * may be thrown during faulty evaluation */ boolean evaluate(E event) throws NullPointerException, EvaluationException; - - - - + /** * Evaluators are named entities. * @@ -54,7 +53,6 @@ public interface EventEvaluator<E> extends ContextAware, LifeCycle { */ public String getName(); - /** * Evaluators are named entities. */ diff --git a/logback-core/src/main/java/ch/qos/logback/core/boolex/JaninoEventEvaluatorBase.java b/logback-core/src/main/java/ch/qos/logback/core/boolex/JaninoEventEvaluatorBase.java index 5e03a16..fce2ad3 100644 --- a/logback-core/src/main/java/ch/qos/logback/core/boolex/JaninoEventEvaluatorBase.java +++ b/logback-core/src/main/java/ch/qos/logback/core/boolex/JaninoEventEvaluatorBase.java @@ -18,7 +18,14 @@ import java.util.List; import org.codehaus.janino.ExpressionEvaluator; -abstract public class JaninoEventEvaluatorBase<E> extends EventEvaluatorBase<E>{ +/** + * Abstract class which sets the groundwork for janino based evaluations. + * + * @author Ceki Gülcü + * + * @param <E> + */ +abstract public class JaninoEventEvaluatorBase<E> extends EventEvaluatorBase<E> { static Class EXPRESSION_TYPE = boolean.class; static Class[] THROWN_EXCEPTIONS = new Class[1]; @@ -27,7 +34,6 @@ abstract public class JaninoEventEvaluatorBase<E> extends EventEvaluatorBase<E>{ static { THROWN_EXCEPTIONS[0] = EvaluationException.class; } - private String expression; @@ -60,7 +66,8 @@ abstract public class JaninoEventEvaluatorBase<E> extends EventEvaluatorBase<E>{ public boolean evaluate(E event) throws EvaluationException { if (!isStarted()) { - throw new IllegalStateException("Evaluator [" + name + "] was called in stopped state"); + throw new IllegalStateException("Evaluator [" + name + + "] was called in stopped state"); } try { Boolean result = (Boolean) ee.evaluate(getParameterValues(event)); diff --git a/logback-examples/src/main/java/chapter6/SampleFilter.java b/logback-examples/src/main/java/chapter6/SampleFilter.java index a4b60c6..bf7ee9d 100644 --- a/logback-examples/src/main/java/chapter6/SampleFilter.java +++ b/logback-examples/src/main/java/chapter6/SampleFilter.java @@ -17,11 +17,10 @@ import ch.qos.logback.classic.spi.ILoggingEvent; import ch.qos.logback.core.filter.Filter; import ch.qos.logback.core.spi.FilterReply; -public class SampleFilter extends Filter { +public class SampleFilter extends Filter<ILoggingEvent> { @Override - public FilterReply decide(Object eventObject) { - ILoggingEvent event = (ILoggingEvent)eventObject; + public FilterReply decide(ILoggingEvent event) { if (event.getMessage() != null && event.getMessage().contains("sample")) { return FilterReply.ACCEPT; } else { diff --git a/logback-examples/src/main/java/chapter6/thresholdFilterConfig.xml b/logback-examples/src/main/java/chapter6/thresholdFilterConfig.xml index 4e6738e..bcdb27f 100644 --- a/logback-examples/src/main/java/chapter6/thresholdFilterConfig.xml +++ b/logback-examples/src/main/java/chapter6/thresholdFilterConfig.xml @@ -2,14 +2,19 @@ <configuration> <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> + +  <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>INFO</level> </filter> - <layout class="ch.qos.logback.classic.PatternLayout"> + <layout> <pattern>%-4relative [%thread] %-5level %logger{30} - %msg%n</pattern> </layout> </appender> + + <root level="DEBUG"> <appender-ref ref="CONSOLE" /> </root> + </configuration> \ No newline at end of file diff --git a/logback-site/src/site/pages/manual/filters.html b/logback-site/src/site/pages/manual/filters.html index 3d0ebb9..957ba15 100644 --- a/logback-site/src/site/pages/manual/filters.html +++ b/logback-site/src/site/pages/manual/filters.html @@ -60,69 +60,62 @@ <h3><a name="filter" href="#filter">Regular filters</a></h3> - Any regular logback-classic filter extends the <a + Regular logback-classic filters extend the <a href="../xref/ch/qos/logback/core/filter/Filter.html"><code>Filter</code></a> - abstract class which consists of the <code>decide(Object - event)</code> method taking an <code>ILoggingEvent</code> instance - as parameter. Logback-classic will ask any given filter to decide - what to do with newly created events. + abstract class which essentially consists of a single method, + <code>decide()</code> method taking an <code>ILoggingEvent</code> + instance as parameter. Filters are organized as an ordered list and are based on - ternary logic. The <code>decide(Object event)</code> method of - each filter is called in sequence. This method returns one of the - <a + ternary logic. The <code>decide(ILoggingEvent event)</code> method + of each filter is called in sequence. This method returns one of + the <a href="../xref/ch/qos/logback/core/spi/FilterReply.html"><code>FilterReply</code></a> - enumeration values, i.e. one of <code>FilterReply.DENY</code>, - <code>FilterReply.NEUTRAL</code> or - <code>FilterReply.ACCEPT</code>. If the value returned by - <code>decide</code>() is <code>FilterReply.DENY</code>, then the + enumeration values, i.e. one of <code>DENY</code>, + <code>NEUTRAL</code> or <code>ACCEPT</code>. If the value + returned by <code>decide</code>() is <code>DENY</code>, then the log event is dropped immediately without consulting the remaining - filters. If the value returned is - <code>FilterReply.NEUTRAL</code>, then the next filter in the - chain is consulted. If there are no further filters to consult, - then the logging event is processed normally. If the returned - value is <code>FilterReply.ACCEPT</code>, then the logging event - is processed immediately skipping the remaining filters. + filters. If the value returned is <code>NEUTRAL</code>, then the + next filter in the list is consulted. If there are no further + filters to consult, then the logging event is processed normally. + If the returned value is <code>ACCEPT</code>, then the logging + event is processed immediately skipping the invocation of the + remaining filters. - In logback-classic <code>Filter</code> objects can be added to - <code>Appender</code> instances. By adding filters to an appender - you can filter events by various criteria, such as the contents of - the log message, the contents of the MDC, the time of day or any - other part of the logging event. + In logback-classic, filters can be added to + <code>Appender</code> instances. By adding one or more filters to + an appender, you can filter events by arbitrary criteria, such as + the contents of the log message, the contents of the MDC, the time + of day or any other part of the logging event. <h3>Implementing your own Filter</h3> - Creating your own filter is not difficult. All you have to do - is extend the <code>Filter</code> abstract class. The only method - that you will have to implement is the <code>decide()</code> - method, allowing you to concentrate only on the behaviour of your - filter. + Creating your own filter is easy. All you have to do is extend + the <code>Filter</code> abstract class and implement the + <code>decide()</code> method. - The next class is all it takes to implement one's own - filter. All it does is accept logging events who's message - contains the String sample. The filter will give a - neutral response to any logging event whose message does not - contain this String. + The SampleFilter class shown below provides an example. Its + <code>decide</code> method returns ACCEPT for logging events + containing the string "sample" in its message field. For other + events, the value NEUTRAL is returned. Example 6.1: Basic custom filter (<a href="../xref/chapter6/SampleFilter.html">logback-examples/src/main/java/chapter6/SampleFilter.java</a>) <pre class="prettyprint source">package chapter6; -import ch.qos.logback.classic.spi.LoggingEvent; +import ch.qos.logback.classic.spi.ILoggingEvent; import ch.qos.logback.core.filter.Filter; import ch.qos.logback.core.spi.FilterReply; -public class SampleFilter extends Filter { +public class SampleFilter extends Filter>ILoggingEvent> { @Override - public FilterReply decide(Object eventObject) { - LoggingEvent event = (LoggingEvent)eventObject; - + public FilterReply decide(ILoggingEvent event) { if (event.getMessage().contains("sample")) { return FilterReply.ACCEPT; } else { @@ -131,16 +124,14 @@ public class SampleFilter extends Filter { } }</pre> - - What is shown above might be the simplest filter. Like any filter, it - can be attached to any appender using the <Filter> element, as - shown below: + The configutation files shown next attaches a + <code>SampleFilter</code> to a <code>ConsoleAppener</code>. Example 6.2: SampleFilter configuration (logback-examples/src/main/java/chapter6/SampleFilterConfig.xml) <pre class="prettyprint source"><configuration> - <appender name="STDOUT" - class="ch.qos.logback.core.ConsoleAppender"> + <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> + <Filter class="chapter6.SampleFilter" /> <layout class="ch.qos.logback.classic.PatternLayout"> @@ -155,34 +146,41 @@ public class SampleFilter extends Filter { </root> </configuration></pre> - Thanks to Joran, logback's powerful configuration framework, - adding an option to such a filter is very easy. Just add the - corresponding getter and setter methods in the class, and you can - specify the option's value in an xml element, nested within the - filter element. + With the help of Joran, logback's configuration framework, + specifiying properties or sub-componenets to filters is also + easy. After adding the corresponding setter method in the filter + class, specify the value of the property in an xml element named + after the property, nesting it within <code><filter></code> + element. - In case you want to implement a filter that provides different - behaviour depending on the result of its test (say, a filter that - would accept or deny an event depending on the content of its - message), you can extend the - <a href="../xref/ch/qos/logback/core/filter/AbstractMatcherFilter.html"> - <code>AbstractMatcherFilter</code></a> class. It will provide - your filter with two properties: OnMatch and - OnMismatch, both of which can be configured like any - other property. - + Often times, the desired filter logic consists of two + orthogonal parts, a match/mismatch test and a response depending + on the match/mismatch. For example, for a given test, say message + equals "foobar", one filter might respond ACCEPT on match and + NEUTRAL on mismatch, and another filter might respond NEUTRAL on + match and DENY on mismatch. + + + Taking notice of this orthogonality, logback ships with the <a + href="../xref/ch/qos/logback/core/filter/AbstractMatcherFilter.html"> + <code>AbstractMatcherFilter</code></a> class which provides a + useful skeleton for specifiying the appropriate response on match + and on mistmatch, with the help of two properties, named + OnMatch and OnMismatch. Most of the regular + filters included in logback are derived from + <code>AbstractMatcherFilter</code>. + - <h3>Logback Filters</h3> + <h3><a name="levelFilter" href="#levelFilter">LevelFilter</a></h3> - At the moment, there are two filters that ship with logback. <a - href="../xref/ch/qos/logback/classic/LevelFilter.html"> - <code>LevelFilter</code></a> provides event filtering based on a - <code>Level</code> value. If the event's level is equal to the - configured level, the filter accepts or denies the event, - depending on its configuration. It allows you to choose the - behaviour of logback for a precise given level. Here is a sample - configuration that uses <code>LevelFilter</code>. + <a href="../xref/ch/qos/logback/classic/LevelFilter.html"> + <code>LevelFilter</code></a> filters events based on exact level + matching. If the event's level is equal to the configured level, + the filter accepts or denies the event, depending on the + configuration of the onMatch and onMismatch properties. Here is a sample + configuration file. Example 6.3: Sample LevelFilter configuration (logback-examples/src/main/java/chapter6/levelFilterConfig.xml) @@ -194,7 +192,7 @@ public class SampleFilter extends Filter { <onMatch>ACCEPT</onMatch> <onMismatch>DENY</onMismatch> </filter> - <layout class="ch.qos.logback.classic.PatternLayout"> + <layout> <pattern> %-4relative [%thread] %-5level %logger{30} - %msg%n </pattern> @@ -205,23 +203,27 @@ public class SampleFilter extends Filter { </root> </configuration></pre> - - The second filter that ships with logback is - <a href="../xref/ch/qos/logback/classic/ThresholdFilter.html"> - <code>ThresholdFilter</code></a>. - It is also based on level value, but acts as a threshold to deny any request - whose level is not equal or greater to the configured level. A sample - use of the <code>ThresholdFilter</code> is shown below. + <h3><a name="thresholdFilter" href="#thresholdFilter">ThresholdFilter</a></h3> + + The <a + href="../xref/ch/qos/logback/classic/ThresholdFilter.html"> + <code>ThresholdFilter</code></a> filters events below the + specified threshold. For events of level equal or above the + threshold, <code>ThresholdFilter</code> will respond NEUTRAL when + its <code>decide</code>() method is invoked. However, events with + a level below the threshold will be denied. Here is a sample + configuration file. Example 6.4: Sample ThresholdFilter configuration (logback-examples/src/main/java/chapter6/thresholdFilterConfig.xml) <pre class="prettyprint source"><configuration> <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> +  <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>INFO</level> </filter> - <layout class="ch.qos.logback.classic.PatternLayout"> + <layout> <pattern> %-4relative [%thread] %-5level %logger{30} - %msg%n </pattern> @@ -233,8 +235,27 @@ public class SampleFilter extends Filter { </configuration></pre> - <h3>Evaluator Filters taking Java Expressions</h3> + <h3><a name="evalutatorFilter" + href="#evalutatorFilter">EvaluatorFilter</a></h3> + <a + href="../xref/ch/qos/logback/core/filter/EvaluatorFilter.html"><code>EvaluatorFilter</code></a> + is a generic filter encapsulating an <a + href="../xref/ch/qos/logback/core/boolex/EventEvaluator.html"> + <code>EventEvaluator</code></a> which evaluates whether a given + criteria is met. On match and respectively on mismatch, the + <code>EvaluatorFilter</code> will return the value set for the + OnMatch and respectively for the OnMismatch properties. + + + The <code>EventEvaluator</code> class is abstract and you can + implement your own even evaluation logic. Logback-classic ships + with a concrete evaluator implementation called <a + href="../xref/ch/qos/logback/classic/boolex/JaninoEvaluator.html">JaninoEvaluator</a> + which take artibtrary java expressions as the evaluation criteria, + enabling unprecedented flexibility for filtering logging events. + A special category of filters is implemented by the <a href="../xref/ch/qos/logback/core/filter/EvaluatorFilter.html"> ----------------------------------------------------------------------- Summary of changes: logback-classic/pom.xml | 4 +- .../classic/boolex/JaninoEventEvaluator.java | 1 - .../ch/qos/logback/classic/filter/LevelFilter.java | 26 ++-- .../logback/classic/filter/ThresholdFilter.java | 14 +- .../classic/boolex/JaninoEventEvaluatorTest.java | 19 ++ .../ch/qos/logback/core/boolex/EventEvaluator.java | 36 ++-- .../core/boolex/JaninoEventEvaluatorBase.java | 13 +- .../src/main/java/chapter6/SampleFilter.java | 5 +- .../main/java/chapter6/thresholdFilterConfig.xml | 7 +- logback-site/src/site/pages/manual/filters.html | 177 +++++++++++--------- 10 files changed, 171 insertions(+), 131 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

branch, master, updated. 93098a6ca9cfb47dc87cd10e035d5f678723b1f5
by git-noreply＠pixie.qos.ch 08 Nov '09

08 Nov '09

The branch, master has been updated via 93098a6ca9cfb47dc87cd10e035d5f678723b1f5 (commit) via 9700a02ae011baf8d9404f8417485105f0ec5a02 (commit) via 1d9a3a816478905ffb518fbd0603c7ec1e0f5e02 (commit) via 5a457959b54a496b8d4a01c73ba1443edab66c20 (commit) from 61bfd0d0ba8d095ce395ab763f8047307a58c418 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=93098a6ca9cfb47dc87cd10e… http://github.com/ceki/logback/commit/93098a6ca9cfb47dc87cd10e035d5f678723b… commit 93098a6ca9cfb47dc87cd10e035d5f678723b1f5 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Sun Nov 8 22:30:41 2009 +0100 - edits in filters.html diff --git a/logback-site/src/site/pages/manual/filters.html b/logback-site/src/site/pages/manual/filters.html index 6127521..3d0ebb9 100644 --- a/logback-site/src/site/pages/manual/filters.html +++ b/logback-site/src/site/pages/manual/filters.html @@ -37,67 +37,61 @@ <script src="../templates/creative.js" type="text/javascript"></script> - As we have seen, logback has several built-in ways for - filtering log requests, including the context-wide filter, - logger-level selection rule and appender filters. These provide - high performance filtering for the most commonly encountered - cases. These filters are largely inspired from Linux ipchains or - iptables as they are called in more recent Linux kernels. - Logback filters are based on ternary logic allowing them to be - assembled or chained together to compose an arbitrarily complex - filtering policy. + In the preceding chapters, the <a + href="architecture.html#basic_selection">basic selection rule</a>, + which lies at the heart of logback-classic, has been presented. In + this chapter, additional filtering methods will be introduced. + + + + Logback filters are based on ternary logic allowing them to be + assembled or chained together to compose an arbitrarily complex + filtering policy. They are largely inspired by Linux's iptables. <script src="../templates/setup.js" type="text/javascript"></script> - - There are two main types of filters, namely <code>Filter</code> and - <code>TurboFilter</code>. + <h2>In logback-classic</h2> + + + Logback-classic offers two types of filters, regular filters + and turbo filters. - <h2>Logback Classic</h2> - - <a name="Filter"></a> + <h3><a name="filter" href="#filter">Regular filters</a></h3> - <code>Filter</code> objects all extend the <a + Any regular logback-classic filter extends the <a href="../xref/ch/qos/logback/core/filter/Filter.html"><code>Filter</code></a> - abstract class. The <code>decide(Object event)</code> method is - passed a newly created <code>ILoggingEvent</code> instance. + abstract class which consists of the <code>decide(Object + event)</code> method taking an <code>ILoggingEvent</code> instance + as parameter. Logback-classic will ask any given filter to decide + what to do with newly created events. - <h3>Filter chains</h3> - This abstract class assumes that filters are organized in a - linear chain. Its member field next points to the next filter in - the chain, or <code>null</code> if there are no further filters in - the chain. Figure 6.1 depicts a sample filter chain consisting of - three filters. - - - <img src="images/chapter6/filterChain.gif" alt="A sample filter chain"/> - - Filters are based on ternary logic. The <code>decide(Object - event)</code> method of each filter is called in sequence. This - method returns one of the <a - href="../xref/ch/qos/logback/core/spi/FilterReply.html"><code>FilterReply</code></a> - enumeration values, i.e. one of <code>FilterReply.DENY</code>, - <code>FilterReply.NEUTRAL</code> or - <code>FilterReply.ACCEPT</code>. If the returned value is - <code>FilterReply.DENY</code>, then the log event is dropped - immediately without consulting the remaining filters. If the value - returned is <code>FilterReply.NEUTRAL</code>, then the next filter - in the chain is consulted. If there are no further filters to - consult, then the logging event is processed normally. If the - returned value is <code>FilterReply.ACCEPT</code>, then the - logging event is processed immediately skipping the remaining - filters. + Filters are organized as an ordered list and are based on + ternary logic. The <code>decide(Object event)</code> method of + each filter is called in sequence. This method returns one of the + <a + href="../xref/ch/qos/logback/core/spi/FilterReply.html"><code>FilterReply</code></a> + enumeration values, i.e. one of <code>FilterReply.DENY</code>, + <code>FilterReply.NEUTRAL</code> or + <code>FilterReply.ACCEPT</code>. If the value returned by + <code>decide</code>() is <code>FilterReply.DENY</code>, then the + log event is dropped immediately without consulting the remaining + filters. If the value returned is + <code>FilterReply.NEUTRAL</code>, then the next filter in the + chain is consulted. If there are no further filters to consult, + then the logging event is processed normally. If the returned + value is <code>FilterReply.ACCEPT</code>, then the logging event + is processed immediately skipping the remaining filters. - In logback-classic <code>Filter</code> objects can only be - added to <code>Appender</code> instances. By adding filters to an - appender you can filter events by various criteria, such as the - contents of the log message, the contents of the MDC, the time of - day or any other part of the logging event. + In logback-classic <code>Filter</code> objects can be added to + <code>Appender</code> instances. By adding filters to an appender + you can filter events by various criteria, such as the contents of + the log message, the contents of the MDC, the time of day or any + other part of the logging event. <h3>Implementing your own Filter</h3> @@ -745,7 +739,7 @@ configuration (logback-examples/src/main/java/chapter6/duplicateMessage.xml) - <h2>Logback-access</h2> + <h2>In logback-access</h2> Logback-access offers most of the features available with logback-classic. <code>Filter</code> objects are available and http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=9700a02ae011baf8d9404f84… http://github.com/ceki/logback/commit/9700a02ae011baf8d9404f8417485105f0ec5… commit 9700a02ae011baf8d9404f8417485105f0ec5a02 Merge: 61bfd0d 1d9a3a8 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Sun Nov 8 20:01:40 2009 +0100 Merge branch 'master' of github.com:ceki/logback http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=1d9a3a816478905ffb518fbd… http://github.com/ceki/logback/commit/1d9a3a816478905ffb518fbd0603c7ec1e0f5… commit 1d9a3a816478905ffb518fbd0603c7ec1e0f5e02 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Fri Nov 6 23:32:32 2009 +0100 - applied Charles changes on mdc.html diff --git a/logback-examples/src/main/java/chapter7/NumberCruncherServer.java b/logback-examples/src/main/java/chapter7/NumberCruncherServer.java index bc78a14..f952706 100644 --- a/logback-examples/src/main/java/chapter7/NumberCruncherServer.java +++ b/logback-examples/src/main/java/chapter7/NumberCruncherServer.java @@ -86,7 +86,7 @@ public class NumberCruncherServer extends UnicastRemoteObject } while ((n % i) == 0); } - // Placing artificial delays in tight-loops will also lead to + // Placing artificial delays in tight loops will also lead to // sub-optimal resuts. :-) delay(100); } diff --git a/logback-site/src/site/pages/manual/mdc.html b/logback-site/src/site/pages/manual/mdc.html index b22e43a..f9c7437 100644 --- a/logback-site/src/site/pages/manual/mdc.html +++ b/logback-site/src/site/pages/manual/mdc.html @@ -145,7 +145,7 @@ public class SimpleMDC { same key will overwrite older values. The code then proceeds to configure logback. - For the sake of consiceness, we have the omitted the code that + For the sake of conciseness, we have the omitted the code that configures logback with the configuration file <a href="http://tinyurl.com/4gy542">simpleMDC.xml</a>. Here is the relevant section from that file. @@ -186,32 +186,31 @@ Richard Nixon - Attributed to the former US president. 17 Nov 1973.</pre></div> <h3>Advanced Use</h3> - - Mapped Diagnostic Contexts shine brightest within client server - architectures. Typically, multiple clients will be served by - multiple threads on the server. Although the methods in the - <code>MDC</code> class are static, the diagnostic context is - managed on a per thread basis, allowing each server thread to - bear a distinct <code>MDC</code> stamp. <code>MDC</code> - operations such as <code>put()</code> and <code>get()</code> - affect only the <code>MDC</code> of the current thread, - and the children of the current thread. The <code>MDC</code> in - other threads remain unaffected. Given that <code>MDC</code> - information is managed on a per thread basis, each thread will - have its own copy of the <code>MDC</code>. Thus, there is no - need for the developer to worry about thread-safety or - synchronization when programming with the <code>MDC</code> - because it safely and transparently handles these issues. + Mapped Diagnostic Contexts shine brightest within client server + architectures. Typically, multiple clients will be served by + multiple threads on the server. Although the methods in the + <code>MDC</code> class are static, the diagnostic context is + managed on a per thread basis, allowing each server thread to bear + a distinct <code>MDC</code> stamp. <code>MDC</code> operations + such as <code>put()</code> and <code>get()</code> affect only the + <code>MDC</code> of the current thread, and the children + of the current thread. The <code>MDC</code> in other threads + remain unaffected. Given that <code>MDC</code> information is + managed on a per thread basis, each thread will have its own copy + of the <code>MDC</code>. Thus, there is no need for the developer + to worry about thread-safety or synchronization when programming + with the <code>MDC</code> because it handles these issues safely + and transparently. - - The next example is somewhat more advanced. - It shows how the <code>MDC</code> can be used in a client-server setting. - The server-side implements the <code>NumberCruncher</code> interface shown in - Example 7.2 below. <code>The NumberCruncher</code> interface contains a single - method named <code>factor()</code>. Using RMI technology, client invokes the - <code>factor()</code> method of the server application to retrieve the distinct - factors of an integer. + The next example is somewhat more advanced. It shows how the + <code>MDC</code> can be used in a client-server setting. The + server-side implements the <code>NumberCruncher</code> interface + shown in Example 7.2 below. <code>The NumberCruncher</code> + interface contains a single method named + <code>factor()</code>. Using RMI technology, the client invokes + the <code>factor()</code> method of the server application to + retrieve the distinct factors of an integer. Example 7.2: The service interface (<a href="../xref/chapter7/NumberCruncher.html"> @@ -315,7 +314,7 @@ public class NumberCruncherServer extends UnicastRemoteObject } while ((n % i) == 0); } - // Placing artificial delays in tight-loops will also lead to + // Placing artificial delays in tight loops will also lead to // sub-optimal resuts. :-) delay(100); } @@ -390,20 +389,22 @@ public class NumberCruncherServer extends UnicastRemoteObject } }</pre> - - The implementation of the <code>factor(int number)</code> method is - of particular relevance. It starts by putting the client's hostname into the - <code>MDC</code> under the key client. The number to factor, - as requested by the client, is put into the <code>MDC</code> under the key - number. After computing the distinct factors of the integer - parameter, the result is returned to the client. Before returning the - result however, the values for the client and number are - cleared by calling the <code>MDC.remove()</code> method. Normally, - a <code>put()</code> operation should be balanced by the corresponding - <code>remove()</code> operation. Otherwise, the <code>MDC</code> will - contain stale values for certain keys. We would recommend that whenever - possible <code>remove()</code> operations be performed within finally blocks, - ensuring their invocation regardless of the execution path of the code. + The implementation of the <code>factor(int number)</code> + method is of particular relevance. It starts by putting the + client's hostname into the <code>MDC</code> under the key + client. The number to factor, as requested by the client, + is put into the <code>MDC</code> under the key + number. After computing the distinct factors of the + integer parameter, the result is returned to the client. Before + returning the result however, the values for the client + and number are cleared by calling the + <code>MDC.remove()</code> method. Normally, a <code>put()</code> + operation should be balanced by the corresponding + <code>remove()</code> operation. Otherwise, the <code>MDC</code> + will contain stale values for certain keys. We would recommend + that whenever possible, <code>remove()</code> operations be + performed within finally blocks, ensuring their invocation + regardless of the execution path of the code. @@ -519,12 +520,12 @@ public class NumberCruncherServer extends UnicastRemoteObject Within the servlet filter's <code>doFilter</code> method, we - can retreive the relevant user data through the request (or a - cookie threin), store it the <code>MDC</code>. Subsequent - processing by other filters and servlets will automatically - benefit from the MDC data that was stored previously. Finally, - when our servlet filter ragains control, we have an oppurtunity - to clean MDC data. + can retrieve the relevant user data through the request (or a + cookie therein), store it the <code>MDC</code>. Subsequent + processing by other filters and servlets will automatically + benefit from the MDC data that was stored previously. Finally, + when our servlet filter regains control, we have an opportunity to + clean MDC data. Here is an implementation of such a filter: @@ -563,7 +564,7 @@ public class UserServletFilter implements Filter { Principal principal = req.getUserPrincipal(); // Please note that we could have also used a cookie to - // retreive the user name + // retrieve the user name if (principal != null) { String username = principal.getName(); @@ -594,12 +595,13 @@ public class UserServletFilter implements Filter { } }</pre> - - When the filter's <code>doFilter()</code> method is called, is first looks for a - <code>java.security.Principal</code> object in the request. This object contains - the name of the currently authenticated user. In case the user principal is not set, - the filter looks for a session attribute matching a given key (here username). - If a user information is found, it is registered in the <code>MDC</code>. + When the filter's <code>doFilter()</code> method is called, it + first looks for a <code>java.security.Principal</code> object in the + request. This object contains the name of the currently + authenticated user. In case the user principal is not set, the + filter looks for a session attribute matching a given key (here + username). If a user information is found, it is + registered in the <code>MDC</code>. Once the filter chain has completed, the filter removes the user @@ -609,18 +611,18 @@ public class UserServletFilter implements Filter { The approach we just outlined sets MDC data only for the duration of the request and only for the thread processing it. Other threads are unaffected. Furthermore, any given thread will contain correct - MDC data any point in time. + MDC data at any point in time. <h3>MDC And Managed Threads</h3> - A copy of mapped diagnostic context can not always be inherited - by worker thread from the initiating thread. This is the case when - <code>java.util.concurrent.Executors</code> is used for thread - management. For instance, <code>newCachedThreadPool</code> method - creates a <code>ThreadPoolExecutor</code> and like other thread - pooling code it has intricate thread creation logic. + A copy of the mapped diagnostic context can not always be + inherited by worker threads from the initiating thread. This is the + case when <code>java.util.concurrent.Executors</code> is used for + thread management. For instance, <code>newCachedThreadPool</code> + method creates a <code>ThreadPoolExecutor</code> and like other + thread pooling code, it has intricate thread creation logic. In such cases, it is recommended that @@ -628,8 +630,8 @@ public class UserServletFilter implements Filter { (master) thread before submitting a task to the executor. When the task runs, as its first action, it should invoke <code>MDC.setContextMapValues()</code> to associate the stored copy - of the orinal MDC values with the new <code>Executor</code> managed - thread. + of the original MDC values with the new <code>Executor</code> + managed thread. http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=5a457959b54a496b8d4a01c7… http://github.com/ceki/logback/commit/5a457959b54a496b8d4a01c73ba1443edab66… commit 5a457959b54a496b8d4a01c73ba1443edab66c20 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Fri Nov 6 23:17:08 2009 +0100 Applies Charles proof-reading of filters.html diff --git a/logback-site/src/site/pages/manual/filters.html b/logback-site/src/site/pages/manual/filters.html index e15f902..6127521 100644 --- a/logback-site/src/site/pages/manual/filters.html +++ b/logback-site/src/site/pages/manual/filters.html @@ -105,14 +105,14 @@ Creating your own filter is not difficult. All you have to do is extend the <code>Filter</code> abstract class. The only method that you will have to implement is the <code>decide()</code> - method, allowing you to contentrate only on the behaviour of your + method, allowing you to concentrate only on the behaviour of your filter. The next class is all it takes to implement one's own filter. All it does is accept logging events who's message contains the String sample. The filter will give a - neutral response to any logging event who's message does not + neutral response to any logging event whose message does not contain this String. @@ -246,7 +246,7 @@ public class SampleFilter extends Filter { href="../xref/ch/qos/logback/core/filter/EvaluatorFilter.html"> <code>EvaluatorFilter</code></a> class. These filters use an <a href="../xref/ch/qos/logback/core/boolex/EventEvaluator.html"> - <code>EventEvaluator</code></a> object to decide wether to accept + <code>EventEvaluator</code></a> object to decide whether to accept or deny a request. This allows unprecedented flexibility in the way that you can affect filtering of logging events. @@ -256,7 +256,7 @@ public class SampleFilter extends Filter { and to specify an evaluation expression, that is a boolean expression in regular Java syntax. These evaluation expressions are compiled on-the-fly during the interpretation of - the configration file. It is the users reponsibility to ensure + the configuration file. It is the users reponsibility to ensure that the expression is boolean, that it evaluates to true or false. In evaluation expressions, logback implicitly exposes various fields of a logging event as variables. The list of these @@ -327,9 +327,9 @@ public class SampleFilter extends Filter { <td>mdc </td> <td><code>Map</code></td> - <td>A map containing all the MDC values at the time of the - creation of the logging event. A value can be access by using the - following expression: mdc.get("myKey"). + <td>A map containing all the MDC values at the time of the + creation of the logging event. A value can be accessed by + using the following expression: mdc.get("myKey"). </td> </tr> <tr class="alt"> @@ -391,7 +391,7 @@ public class SampleFilter extends Filter { The <a href="../xref/chapter6/FilterEvents.html"><code>FilterEvents</code></a> application issues ten logging requests, numbered 0 to 9. Let us - rist run <code>FilterEvents</code> class without any filters: + first run <code>FilterEvents</code> class without any filters: <div class="source"><pre> @@ -415,7 +415,7 @@ java chapter6.FilterEvents src/main/java/chapter6/basicConfiguration.xml Suppose that we want to get rid of the billing information. The basicEventEvaluator.xml configuration file just - desribed, does exactly what we want. + described, does exactly what we want. Running with filters: java chapter6.FilterEvents src/main/java/chapter6/basicEventEvaluator.xml @@ -442,7 +442,7 @@ java chapter6.FilterEvents src/main/java/chapter6/basicConfiguration.xml the logging event. - Overall, they work much like the previously mentionned + Overall, they work much like the previously mentioned filters. However, there are two main differences between <code>Filter</code> and <code>TurboFilter</code> objects. @@ -458,18 +458,18 @@ java chapter6.FilterEvents src/main/java/chapter6/basicConfiguration.xml <code>TurboFilter</code> objects do not require the instantiation of a logging event to filter a logging request. As such, turbo filters are intended for high performance filtering of logging - event, even before they are created. + events, even before they are created. <h3>Implementing your own TurboFilter</h3> - - To create your own <code>TurboFilter</code> component, just extend the - <code>TurboFilter</code> abstract class. As previously, when implementing - a custumized filter object, developing a custom <code>TurboFilter</code> only - ask that one implement the <code>decide()</code> method. In the next example, we - create a slightly more complex filter: + To create your own <code>TurboFilter</code> component, just + extend the <code>TurboFilter</code> abstract class. As previously, + when implementing a customized filter object, developing a custom + <code>TurboFilter</code> only asks that one implement the + <code>decide()</code> method. In the next example, we create a + slightly more complex filter: Example 6.6: Basic custom <code>TurboFilter</code> (<a href="../xref/chapter6/SampleTurboFilter.html">logback-examples/src/main/java/chapter6/SampleTurboFilter.java</a>) @@ -560,9 +560,9 @@ public class SampleTurboFilter extends TurboFilter { Logback classic ships with several <code>TurboFilter</code> classes ready for use. The <a href="../xref/ch/qos/logback/classic/turbo/MDCFilter.html"><code>MDCFilter</code></a> - check the presence of a given value in the MDC whereas <a + checks the presence of a given value in the MDC whereas <a href="../apidocs/ch/qos/logback/classic/turbo/DynamicThresholdFilter.html"><code>DynamicThresholdFilter</code></a> - allows filtering based on MDC key/level thresold associations. On + allows filtering based on MDC key/level threshold associations. On the other hand, <a href="../xref/ch/qos/logback/classic/turbo/MarkerFilter.html"><code>MarkerFilter</code></a> checks for the presence of a specific marker associated with the @@ -641,7 +641,7 @@ configuration (logback-examples/src/main/java/chapter6/turboFilters.xml) requirements and was accepted. - On the other hand, the 6th request, that is a ERROR + On the other hand, the 6th request, that is an ERROR level request should have been displayed. But it satisfied the second <code>TurboFilter</code> whose OnMatch option is set to DENY. @@ -753,7 +753,7 @@ configuration (logback-examples/src/main/java/chapter6/duplicateMessage.xml)AccessEvent</code>. Thus, a customized filter for logback access follows strictly the same rules as those for - logback-classic, except for the event type recieved as parameter. + logback-classic, except for the event type received as parameter. On the other hand, <code>TurboFilter</code> objects are supported by logback-access. ----------------------------------------------------------------------- Summary of changes: .../main/java/chapter7/NumberCruncherServer.java | 2 +- logback-site/src/site/pages/manual/filters.html | 134 ++++++++++---------- logback-site/src/site/pages/manual/mdc.html | 126 ++++++++++--------- 3 files changed, 129 insertions(+), 133 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[JIRA] Created: (LBCLASSIC-119) Missing Export-Package declarations in logback-classic OSGi bundle
by Pavol Juhos (JIRA) 08 Nov '09

08 Nov '09

Missing Export-Package declarations in logback-classic OSGi bundle ------------------------------------------------------------------ Key: LBCLASSIC-119 URL: http://jira.qos.ch/browse/LBCLASSIC-119 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.15 Environment: OSGi environment Reporter: Pavol Juhos Assignee: Logback dev list Priority: Critical logback-classic OSGi bundle doesn't export logback implementation packages. These packages need to be imported by bundles implementing custom logback Appenders etc. The problem is most likely caused a misconfiguration of maven-bundle-plugin in logback-classic POM. Current configuration: <instructions> <Export-Package>ch.qos.logback.classic.*</Export-Package> <Export-Package>org.slf4j.impl;version=1.5.6</Export-Package> <Import-Package>sun.reflect;resolution:=optional, javax.jms;resolution:=optional, * </Import-Package> <Bundle-RequiredExecutionEnvironment>J2SE-1.5</Bundle-RequiredExecutionEnvironment> </instructions> Suggested configuration: <instructions> <Export-Package>ch.qos.logback.classic.*, org.slf4j.impl;version=1.5.6 </Export-Package> <Import-Package>sun.reflect;resolution:=optional, javax.jms;resolution:=optional, * </Import-Package> <Bundle-RequiredExecutionEnvironment>J2SE-1.5</Bundle-RequiredExecutionEnvironment> </instructions> Second Export-Package declaration seems to override the first one. -- 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

2 1