- logback-dev - mailman3.qos.ch

[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

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

08 Nov '09

The branch, master has been updated via 61bfd0d0ba8d095ce395ab763f8047307a58c418 (commit) from e5c863712b04faf94fab7678f01081f424e03893 (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=61bfd0d0ba8d095ce395ab76… http://github.com/ceki/logback/commit/61bfd0d0ba8d095ce395ab763f8047307a58c… commit 61bfd0d0ba8d095ce395ab763f8047307a58c418 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Sun Nov 8 19:44:41 2009 +0100 applied patch supplied by Hugues Malphettes in LBCLASSIC-165 diff --git a/logback-classic/pom.xml b/logback-classic/pom.xml index 47dda97..26beab2 100644 --- a/logback-classic/pom.xml +++ b/logback-classic/pom.xml @@ -208,8 +208,7 @@ </executions> <configuration> <instructions> - <Export-Package>ch.qos.logback.classic.*</Export-Package> - <Export-Package>org.slf4j.impl;version=1.5.6</Export-Package> + <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, * diff --git a/logback-site/src/site/pages/news.html b/logback-site/src/site/pages/news.html index a0e1217..2efe00d 100644 --- a/logback-site/src/site/pages/news.html +++ b/logback-site/src/site/pages/news.html @@ -28,6 +28,16 @@ <hr width="80%" align="center" /> + <h3>13th of November 2009 - Release of version 0.9.18</h3> + + Fixed Private-Package and Export-Package sections in + logback-classic.jar MANIFEST as reported in <a + href="http://jira.qos.ch/browse/LBCLASSIC-165">LBCLASSIC-165</a> + by applying the relavant patch supplied by Hugues Malphettes. + + + <hr width="80%" align="center" /> + <h3>9th of August 2009 - Release of version 0.9.17</h3> <code>PackagingDataCalculator</code> now correctly deals with ----------------------------------------------------------------------- Summary of changes: logback-classic/pom.xml | 3 +-- logback-site/src/site/pages/news.html | 10 ++++++++++ 2 files changed, 11 insertions(+), 2 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

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

08 Nov '09

The branch, master has been updated via e5c863712b04faf94fab7678f01081f424e03893 (commit) from 0ec1b9eeed802b86dbc791654eeefb59ec327e25 (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=e5c863712b04faf94fab7678… http://github.com/ceki/logback/commit/e5c863712b04faf94fab7678f01081f424e03… commit e5c863712b04faf94fab7678f01081f424e03893 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Sun Nov 8 19:15:58 2009 +0100 - added warm up runs to failing LoggingEventSerializationPerfTest diff --git a/logback-classic/src/test/java/ch/qos/logback/classic/spi/LoggingEventSerializationPerfTest.java b/logback-classic/src/test/java/ch/qos/logback/classic/spi/LoggingEventSerializationPerfTest.java index 862fc18..fe25a2f 100644 --- a/logback-classic/src/test/java/ch/qos/logback/classic/spi/LoggingEventSerializationPerfTest.java +++ b/logback-classic/src/test/java/ch/qos/logback/classic/spi/LoggingEventSerializationPerfTest.java @@ -27,7 +27,7 @@ import org.slf4j.helpers.BogoPerf; import ch.qos.logback.classic.net.NOPOutputStream; import ch.qos.logback.classic.net.testObjectBuilders.Builder; import ch.qos.logback.classic.net.testObjectBuilders.LoggingEventWithParametersBuilder; -import ch.qos.logback.classic.net.testObjectBuilders.TrivialLoggingEventBuilder; +import ch.qos.logback.classic.net.testObjectBuilders.TrivialLoggingEventBuilder; import ch.qos.logback.core.CoreConstants; import ch.qos.logback.core.testUtil.Env; @@ -89,18 +89,17 @@ public class LoggingEventSerializationPerfTest { } TrivialLoggingEventBuilder builder = new TrivialLoggingEventBuilder(); - doLoop(builder, LOOP_LEN); - noos.reset(); - double avg = doLoop(builder, LOOP_LEN); noos.reset(); - avg += doLoop(builder, LOOP_LEN); noos.reset(); - avg += doLoop(builder, LOOP_LEN); - - avg = avg/3; + for (int i = 0; i < 3; i++) { + doLoop(builder, LOOP_LEN); + noos.reset(); + } + double rt = doLoop(builder, LOOP_LEN); + System.out + .println("avetage time per logging event " + rt + " nanoseconds"); - System.out.println("avetage time per logging event "+avg+" nanoseconds"); - - long averageSize = (long) (noos.size()/(LOOP_LEN)); - System.out.println("noos size "+noos.size()+ " average size="+averageSize); + long averageSize = (long) (noos.size() / (LOOP_LEN)); + System.out.println("noos size " + noos.size() + " average size=" + + averageSize); double averageSizeLimit = 60; assertTrue("average size " + averageSize + " should be less than " @@ -108,10 +107,9 @@ public class LoggingEventSerializationPerfTest { // the reference was computed on Orion (Ceki's computer) long referencePerf = 5000; - BogoPerf.assertDuration(avg, referencePerf, CoreConstants.REFERENCE_BIPS); + BogoPerf.assertDuration(rt, referencePerf, CoreConstants.REFERENCE_BIPS); } - - + @Test public void testPerformanceWithParameters() { if (Env.isLinux()) { @@ -119,19 +117,23 @@ public class LoggingEventSerializationPerfTest { } LoggingEventWithParametersBuilder builder = new LoggingEventWithParametersBuilder(); - doLoop(builder, LOOP_LEN); - noos.reset(); - double avg = doLoop(builder, LOOP_LEN); - long averageSize = (long) (noos.size()/(LOOP_LEN)); + // warm up + for (int i = 0; i < 3; i++) { + doLoop(builder, LOOP_LEN); + noos.reset(); + } + double rt = doLoop(builder, LOOP_LEN); + long averageSize = (long) (noos.size() / (LOOP_LEN)); + + System.out.println("noos size " + noos.size() + " average size=" + + averageSize); - System.out.println("noos size "+noos.size()+ " average size="+averageSize); - double averageSizeLimit = 160; assertTrue("averageSize " + averageSize + " should be less than " + averageSizeLimit, averageSizeLimit > averageSize); // the reference was computed on Orion (Ceki's computer) long referencePerf = 7000; - BogoPerf.assertDuration(avg, referencePerf, CoreConstants.REFERENCE_BIPS); + BogoPerf.assertDuration(rt, referencePerf, CoreConstants.REFERENCE_BIPS); } } ----------------------------------------------------------------------- Summary of changes: .../spi/LoggingEventSerializationPerfTest.java | 46 ++++++++++--------- 1 files changed, 24 insertions(+), 22 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

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

06 Nov '09

The branch, master has been updated via 0ec1b9eeed802b86dbc791654eeefb59ec327e25 (commit) from 0acd6c2cbb7b85bbd909411e6ad470a5e0d3c64b (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=0ec1b9eeed802b86dbc79165… http://github.com/ceki/logback/commit/0ec1b9eeed802b86dbc791654eeefb59ec327… commit 0ec1b9eeed802b86dbc791654eeefb59ec327e25 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Fri Nov 6 20:01:08 2009 +0100 - applied patch corresponding to Charles' commit 54534d77268ae8a00f0848ddb916879c8820ba18 dated October 07, 2009 diff --git a/logback-site/src/site/pages/manual/appenders.html b/logback-site/src/site/pages/manual/appenders.html index 3051ea3..debc52e 100644 --- a/logback-site/src/site/pages/manual/appenders.html +++ b/logback-site/src/site/pages/manual/appenders.html @@ -315,7 +315,7 @@ public class ExitWoes1 { lc.reset(); // we want to override the default-config. WriterAppender<ILoggingEvent> writerAppender = new WriterAppender<ILoggingEvent>(); writerAppender.setContext(lc); - writerAppender.setLayout(new EchoLayout<<ILoggingEvent>()); + writerAppender.setLayout(new EchoLayout<ILoggingEvent>()); OutputStream os = new FileOutputStream("exitWoes1.log"); writerAppender.setWriter(new OutputStreamWriter(os)); @@ -348,7 +348,7 @@ public class ExitWoes1 { uses this statement and outputs a logging request. - The <code>WriterAppender</code> is the super class of three other + The <code>WriterAppender</code> is the superclass of three other appenders, namely <code>ConsoleAppender</code>, <code>FileAppender</code> which in turn is the super class of <code>RollingFileAppender</code>. The next figure illustrates the @@ -480,7 +480,7 @@ public class ExitWoes1 { class="option">BufferedIO to true automatically sets the ImmediateFlush option to false. The name BufferedIO is slightly - misleading because buffered IO is already supported by + misleading because buffered I/O is already supported by <code>OutputStreamWriter</code>. Setting BufferedIO to true has the effect of buffering I/O as well as character to raw byte conversions, @@ -557,7 +557,7 @@ public class ExitWoes1 { </tr> </table> - By default, <code>FileAppender</code> performs a flushes each + By default, <code>FileAppender</code> performs a flush on each event, ensuring that events are immediately written to disk. Setting the ImmediateFlush option to false can drastically reduce I/O activity by letting @@ -612,7 +612,7 @@ public class ExitWoes1 { </h3> During the application development phase or in the case of - short-lived applications, e.g. batch applications, it is desriable + short-lived applications, e.g. batch applications, it is desirable to create a new log file at each new application launch. This is fairly easy to do with the help of the <code><timestamp></code> element. Here's an example. @@ -763,8 +763,7 @@ public class ExitWoes1 { <ol> <li>In prudent mode, file compression is not supported nor allowed. (We can't have one JVM writing to a file while - another JVM is compressing it.) - </li> + another JVM is compressing it.) </li> <li>The File property of <code>FileAppender</code> cannot be set and must be left @@ -1357,7 +1356,7 @@ public interface RollingPolicy extends LifeCycle { Size and time based archiving supports cleaning of old archive files. You just need to specify the number of periods to preserve - within the <code><MaxHistory></code> element. When your + with the <code><MaxHistory></code> element. When your application is stopped and restarted, logging will continue at the correct location, i.e. at the largest index number for the current period. @@ -1475,7 +1474,7 @@ public interface TriggeringPolicy<E> extends LifeCycle { which implements the <code>ILoggingEvent</code> interface. Nevertheless, remote logging is non-intrusive as far as the logging event is concerned. On the receiving end after - desrialization, the event can be logged as if it were generated + deserialization, the event can be logged as if it were generated locally. Multiple <code>SocketAppender</code> instances running on different machines can direct their logging output to a central log server whose format is fixed. <code>SocketAppender</code> @@ -1675,7 +1674,7 @@ public interface TriggeringPolicy<E> extends LifeCycle { Allow us to repeat for emphasis that serialization of logging - events is not intrusive. A desrialized event carries the same + events is not intrusive. A deserialized event carries the same information as any other logging event. It can be manipulated as if it were generated locally; except that serialized logging events by default do not include caller data. Here is an example @@ -1944,8 +1943,8 @@ Context ctx = new InitialContext(env);</pre> store and forward messaging comes at a hefty price. In return for increased cost, JMS messaging provides decoupling of sender and receiver. As long as the JMS provider is reachable, messages will - eventually arrive at destination. However, what if the JMS server - is down or simply unreachable? + eventually arrive at the destination. However, what if the JMS + server is down or simply unreachable? According to the JMS specification, producers can mark a @@ -2431,8 +2430,8 @@ Context ctx = new InitialContext(env);</pre> You can pass the required parameters on the command line: -<div class="source"><pre>java -Dfrom=source(a)xyz.com -Dto=recipient(a)xyz.com - -DsmtpHost=some_smtp_host src/main/java/chapter4.mail.EMail 10000 chapter4/mail/mail2.xml +<div class="source"><pre>java -Dfrom=source(a)xyz.com -Dto=recipient(a)xyz.com -DsmtpHost=some_smtp_host \ + src/main/java/chapter4.mail.EMail 10000 chapter4/mail/mail2.xml </pre></div> Be sure to replace with values as appropriate for your @@ -2464,7 +2463,7 @@ Context ctx = new InitialContext(env);</pre> "View→Message Body As→Original HTML" option must be set. Yahoo!Mail's support for HTML email, in particular its CSS support is very good. GMail on the other hand, while it - honors the basic HTML table structure, ignores the internal-CSS + honors the basic HTML table structure, ignores the internal CSS formatting. Gmail supports inline CSS formatitng but since inline CSS would make the resulting output too voluminous, <code>HTMLLayout</code> does not use inline CSS. @@ -3175,9 +3174,9 @@ public class CounterBasedEvaluator extends ContextAwareBase implements EventEval </configuration></pre> With this new configuration, sending 500 logging requests to - the aforementioned MySQL database around 0.5 seconds, for an - average time of 1 millisecond per request, i.e. equivalent to a - tenfold improvement in performance. + the aforementioned MySQL database takes around 0.5 seconds, for an + average of 1 millisecond per request, that is a tenfold + improvement in performance. <h3><a name="SyslogAppender" @@ -3416,7 +3415,7 @@ logger.debug("Alice says hello"); href="#WriteYourOwnAppender">Writing your own Appender</a></h3> - You can easily write your appender by sub-classing + You can easily write your appender by subclassing <code>AppenderBase</code>. It handles support for filters, status messages and other functionality shared by most appenders. The derived class only needs to implement one method, namely @@ -3506,8 +3505,8 @@ public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> { The <a href="../xref/chapter4/CountingConsoleAppender.html"><code>CountingConsoleAppender</code></a> - can be configured like any appender. See sample configuration - file + can be configured like any other appender. See sample + configuration file logback-examples/src/main/java/chapter4/countingConsole.xml for an example. @@ -3531,7 +3530,7 @@ public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> { entity by transmitting serialized <code>AccessEvent</code> objects over the wire. Remote logging is non-intrusive as far as the access event is concerned. On the receiving end after - desrialization, the event can be logged as if it were generated + deserialization, the event can be logged as if it were generated locally. @@ -3597,8 +3596,8 @@ public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> { directory. There is a specific script for each of the most popular database systems. If the script for your particular type of database system is missing, it should be quite easy to write one, - taking as example existing scripts. If you send them to us, we - will gladly include missing scripts in future releases. + taking as example one of the existing scripts. You are encouraged + to contribute such missing scripts back to the project. The access_event table's fields are described below: ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/manual/appenders.html | 47 ++++++++++----------- 1 files changed, 23 insertions(+), 24 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0