November 2010 - logback-dev

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.25-40-g1c9ce86
by git-noreply＠pixie.qos.ch 26 Nov '10

26 Nov '10

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Logback: the generic, reliable, fast and flexible logging framework.". The branch, master has been updated via 1c9ce863a577cf5075088eb66ca5353f4de0e209 (commit) via 3fc80dba66c065f80cb098f12916884982205785 (commit) from 474f6003528b4f84583c148a9f9b98c014aa196c (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=1c9ce863a577cf5075088eb6… http://github.com/ceki/logback/commit/1c9ce863a577cf5075088eb66ca5353f4de0e… commit 1c9ce863a577cf5075088eb66ca5353f4de0e209 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Fri Nov 26 13:11:17 2010 +0100 logback-access documentation improvements diff --git a/logback-site/src/site/resources/manual/images/chapters/filters/countingFilter.png b/logback-site/src/site/resources/manual/images/chapters/filters/countingFilter.png new file mode 100644 index 0000000..f64f635 Binary files /dev/null and b/logback-site/src/site/resources/manual/images/chapters/filters/countingFilter.png differ http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=3fc80dba66c065f80cb098f1… http://github.com/ceki/logback/commit/3fc80dba66c065f80cb098f12916884982205… commit 3fc80dba66c065f80cb098f12916884982205785 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Fri Nov 26 13:10:56 2010 +0100 logback-access documentaiton improvements diff --git a/logback-examples/src/main/java/chapters/filters/accessEventEvaluator.xml b/logback-examples/src/main/java/chapters/filters/accessEventEvaluator.xml index 513cdd7..df0d56f 100644 --- a/logback-examples/src/main/java/chapters/filters/accessEventEvaluator.xml +++ b/logback-examples/src/main/java/chapters/filters/accessEventEvaluator.xml @@ -1,20 +1,17 @@ <configuration> + <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" /> - <appender name="STDOUT" - class="ch.qos.logback.core.ConsoleAppender"> - <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> - <evaluator name="myEval"> - <expression>event.getStatusCode() == 404</expression> - </evaluator> - <OnMismatch>NEUTRAL</OnMismatch> - <OnMatch>ACCEPT</OnMatch> - </filter> - <layout class="ch.qos.logback.access.PatternLayout"> - <pattern> - %h %l %u %t %r %s %b - </pattern> - </layout> - </appender> + <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> + <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> + <evaluator> + <expression>event.getStatusCode() == 404</expression> + </evaluator> + <onMismatch>DENY</onMismatch> + <onMatch>ACCEPT</onMatch> + </filter> - <appender-ref ref="STDOUT" /> + <encoder><pattern>%h %l %u %t %r %s %b</pattern></encoder> + </appender> + + <appender-ref ref="STDOUT" /> </configuration> \ No newline at end of file diff --git a/logback-examples/src/main/java/chapters/filters/accessEventEvaluator2.xml b/logback-examples/src/main/java/chapters/filters/accessEventEvaluator2.xml index 116061a..617e940 100644 --- a/logback-examples/src/main/java/chapters/filters/accessEventEvaluator2.xml +++ b/logback-examples/src/main/java/chapters/filters/accessEventEvaluator2.xml @@ -1,27 +1,21 @@ <configuration> + <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" /> - <appender name="STDOUT" - class="ch.qos.logback.core.ConsoleAppender"> - <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> - <evaluator name="Eval404"> - <expression>event.getStatusCode() == 404</expression> - </evaluator> - <OnMismatch>NEUTRAL</OnMismatch> - <OnMatch>ACCEPT</OnMatch> - </filter> - <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> - <evaluator name="EvalCSS"> - <expression>event.getRequestURI().contains("css")</expression> - </evaluator> - <OnMismatch>NEUTRAL</OnMismatch> - <OnMatch>DENY</OnMatch> - </filter> - <layout class="ch.qos.logback.access.PatternLayout"> - <pattern> - %h %l %u %t %r %s %b - </pattern> - </layout> - </appender> + <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> + <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> + <evaluator name="Eval404"> + <expression> + (event.getStatusCode() == 404) + &&  + !(event.getRequestURI().contains(".css")) + </expression> + </evaluator> + <onMismatch>DENY</onMismatch> + <onMatch>ACCEPT</onMatch> + </filter> - <appender-ref ref="STDOUT" /> -</configuration> \ No newline at end of file + <encoder><pattern>%h %l %u %t %r %s %b</pattern></encoder> + </appender> + + <appender-ref ref="STDOUT" /> +</configuration> diff --git a/logback-site/src/site/pages/access.html b/logback-site/src/site/pages/access.html index b0c3de9..e639bf1 100644 --- a/logback-site/src/site/pages/access.html +++ b/logback-site/src/site/pages/access.html @@ -417,51 +417,17 @@ CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/mx4j-impl.jar</pre></div> </p> - <h2><code>CountingFilter</code></h2> - - <p>With the help of <a - href="xref/ch/qos/logback/access/filter/CountingFilter.html"><code>CountingFilter</code></a> - class, logback-access can provide statistical data about access to - the web-server. - </p> - - <p>If you wish to make use of <code>CountingFilter</code>, you to - declare it, as any other filter: - </p> - - <pre class="prettyprint source"><configuration> - <b><filter class="ch.qos.logback.access.filter.CountingFilter"> - <name>countingFilter</name> - </filter></b> - - <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> - <encoder> - <pattern>%h %l %u %t \"%r\" %s %b</pattern> - </encoder> - </appender> - - <appender-ref ref="STDOUT" /> -</configuration></pre> - - <p>This component registers itself to the JMX server and publishes - the statistical data such as averages by minute, by hour, by day, - by week, and by month. Last month's, week's, day's, hour's and - minute's counts as well as the total number of access are also - exposed. - </p> - - - <h2><a name="teeFilter" href="#teeFilter"><code>TeeFilter</code></a></h2> + <h2><a name="teeFilter" + href="#teeFilter"><code>TeeFilter</code> <span class="small">(a servlet-filter)</span></a></h2> <p>In order to diagnose bugs in a web-application, it is often handy to capture the client's request as well as the server's - response as is. The <code>TeeFilter</code> was designed precisely - for this purpose. - </p> - - <p>The <code>TeeFilter</code> is a regular servlet filter. Like other - servlet filters, it needs to be declared in your web-application's - <em>web.xml</em> file: + response. The <code>TeeFilter</code> was designed precisely for + this purpose. It should be noted that <code>TeeFilter</code> is a + regular <a + href="http://download.oracle.com/javaee/5/api/javax/servlet/Filter.html">servlet + filter</a>. Like other servlet filters, it needs to be declared in + your web-application's <em>web.xml</em> file: </p> <pre class="prettyprint source"><filter> diff --git a/logback-site/src/site/pages/manual/filters.html b/logback-site/src/site/pages/manual/filters.html index b698e74..5ae6f91 100644 --- a/logback-site/src/site/pages/manual/filters.html +++ b/logback-site/src/site/pages/manual/filters.html @@ -247,18 +247,21 @@ public class SampleFilter extends Filter>ILoggingEvent> { <p><a href="../xref/ch/qos/logback/core/filter/EvaluatorFilter.html"><code>EvaluatorFilter</code></a> - is a generic filter encapsulating an <a + is a generic filter encapsulating an + <code>EventEvaluator</code>. As the name intimates, 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 corresponding - to <span class="option">onMatch</span> and respectively to <span - class="option">onMismatch</span> properties. + <code>EventEvaluator</code></a> evaluates whether a given criteria + is met for a given event. On match and respectively on mismatch, + the hosting <code>EvaluatorFilter</code> will return the value + specified by <span class="option">onMatch</span> and respectively + to <span class="option">onMismatch</span> properties. </p> - <p>The <code>EventEvaluator</code> is an abstract class and you + + <p>Note that <code>EventEvaluator</code> is an abstract class. You can implement your own event evaluation logic by sub-classing - <code>EventEvaluator</code>. + <code>EventEvaluator</code>. </p> @@ -363,11 +366,11 @@ public class SampleFilter extends Filter>ILoggingEvent> { <p>Logback-classic ships with another concrete <code>EventEvaluator</code> implementation called <a href="../xref/ch/qos/logback/classic/boolex/JaninoEventEvaluator.html">JaninoEventEvaluator</a> - which taking artibtrary java language boolean expressions as the + taking arbitrary java language boolean expressions as the evaluation criteria. We refer to such java language boolean - expressions as "<em>evaulation expressions</em>". Evaluation + expressions as "<em>evaluation expressions</em>". Evaluation expressions enable great flexibility in event - filtering.<code>JaninoEventEvaluator</code> requires the <a + filtering. <code>JaninoEventEvaluator</code> requires the <a href="http://docs.codehaus.org/display/JANINO/Home">Janino library</a>. Please see the <a href="../setup.html#janino">corresponding section</a> of the setup @@ -381,14 +384,15 @@ public class SampleFilter extends Filter>ILoggingEvent> { <p>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 java-language expression is - boolean, that it evaluates to true or false. </p> + reponsibility to ensure that the java-language expression returns + a boolean, i.e. that it evaluates to true or false. </p> - <p>Given that an evaluation expression acts on the current logging - event, logback automatically exports various fields of the logging - event as variables accessible from the evaluation expression. The - case-sensitive names these variables is listed below. + <p>The evaluation expression is evaluated on the current logging + event. Logback-classic automatically exports various fields of the + logging event as variables accessible from the evaluation + expression. The case-sensitive names of these exported variables + are listed below. </p> <table class="bodyTable"> @@ -1002,85 +1006,158 @@ logger.debug("Hello {}.", name1);</pre> because only 5 repetitions are allowed by default. </p> - <h2>In logback-access</h2> + <h1><a name="logbac-access" href="#logback-access">In logback-access</a></h1> <p>Logback-access offers most of the features available with - logback-classic. <code>Filter</code> objects are available and - work in the same way as their logback-classic counterparts. They - handle access' implementation of logging events: - <code>AccessEvent</code>. Thus, a customized filter for logback - access follows strictly the same rules as those for - logback-classic, except for the event type received as parameter. - On the other hand, <code>TurboFilter</code> objects are supported - by logback-access. + logback-classic. In particular, <code>Filter</code> objects are + available and work in the same way as their logback-classic + counterparts, with one notable difference. Instead of + <code>LoggingEvent</code> instances logback-access filters act + upon <a + href="../xref/ch/qos/logback/access/spi/AccessEvent.html"><code>AccessEvent</code></a> + instances. At present time, logback-access ships with a limited + number of filters described below. If you would like to suggest + additional filters, please contact the logback-dev mailing list. </p> + + <h2><a name="countingFilter" + href="#countingFilter"><code>CountingFilter</code></a></h2> + + <p>With the help of <a + href="xref/ch/qos/logback/access/filter/CountingFilter.html"><code>CountingFilter</code></a> + class, logback-access can provide statistical data about access to + the web-server. Upon initialization, <code>CountingFilter</code> + registers itself as an MBean onto the platform's JMX server. You + can then interrogate that MBean for statistical data, + e.g. averages by minute, hour, day, week, or month. Other + statistics such the count for the preceding week, day, hour or + month as well as the total count are also available. + </p> + + <p>The following <em>logback-access.xml</em> configuration file + declares a <code>CountingFilter</code>. </p> + + <pre class="prettyprint source"><configuration> + <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" /> + + <b><filter class="ch.qos.logback.access.filter.CountingFilter"> + <name>countingFilter</name> + </filter></b> + + <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> + <encoder> + <pattern>%h %l %u %t \"%r\" %s %b</pattern> + </encoder> + </appender> + + <appender-ref ref="STDOUT" /> +</configuration></pre> + + <p>You can examine the various statistics maintained by + <code>CountingFilter</code> on your platform's JMX server via the + <code>jconsole</code> application. </p> + + + <img alt="CountingFilter via jconsole" src="images/chapters/filters/countingFilter.png" /> + + <h3><a name="access_EvalutorFilter" + href="#access_EvalutorFilter"><code>EvaluatorFilter</code></a></h3> + - <h3>Filters</h3> - - <p><code>EvaluatorFilter</code> objects with java expressions - supplied in in <code>evaluator</code> configuration elements are - supported by logback-access. However, list implicit variables - available for constructing an expression are different. Only the - <code>AccessEvent</code> object can be used by inserting the - <em>event</em> variable in the expression. Nevertheless the access - <code>evaluator</code> is just as powerfull. All the request and - response components are reachable from the <em>event</em> - variable. - </p> - - <p>Here is a sample configuration that will ensure that any 404 - error will be logged: + <p><a + href="../xref/ch/qos/logback/core/filter/EvaluatorFilter.html"><code>EvaluatorFilter</code></a> + is a generic filter encapsulating an + <code>EventEvaluator</code>. As the name intimates, an + <a + href="../xref/ch/qos/logback/core/boolex/EventEvaluator.html"> + <code>EventEvaluator</code></a> evaluates whether a given criteria + is met for a given event. On match and respectively on mismatch, + the hosting <code>EvaluatorFilter</code> will return the value + specified by <span class="option">onMatch</span> and respectively + to <span class="option">onMismatch</span> properties. Note that + <code>EvaluatorFilter</code> has been previously discussed in the + context of logback-classic (<a href="#evalutatorFilter">see + above</a>). The present text is mostly a repetition of the + previous discussion.</p> + + + <p>Note that <code>EventEvaluator</code> is an abstract class. You + can implement your own event evaluation logic by sub-classing + <code>EventEvaluator</code>. Logback-access ships with a concrete + implementation named <a + href="../xref/ch/qos/logback/access/boolex/JaninoEventEvaluator.html">JaninoEventEvaluator</a>. + It takes arbitrary java language boolean expressions as the + evaluation criteria. We refer to such java language boolean + expressions as "<em>evaluation expressions</em>". Evaluation + expressions enable great flexibility in event + filtering. <code>JaninoEventEvaluator</code> requires the <a + href="http://docs.codehaus.org/display/JANINO/Home">Janino + library</a>. Please see the <a + href="../setup.html#janino">corresponding section</a> of the setup + document. + </p> + + <p>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 java-language expression returns + a boolean, i.e. that it evaluates to true or false. </p> + + + <p>The evaluation expression is evaluated on the current access + event. Logback-access automatically exports the current + <code>AccessEvent</code> instance under the variable name + <b><code>event</code></b>. You can read the various data + associated with the HTTP request as well as the HTTP response via + the <code>event</code> variable. Please refer to the the <a + href="../xref/ch/qos/logback/access/spi/AccessEvent.html"><code>AccessEvent</code> + class source code</a> for the exact list. </p> + + <p>The next logback-access configuration file illustrates + filtering based on the <a + href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5">404 + (Not Found)</a> HTTP response code. Every request resulting in a + 404 will be printed on the console.</p> <em>Example: Access Evaluator (logback-examples/src/main/java/chapters/filters/accessEventEvaluator.xml)</em> <pre class="prettyprint source"><configuration> + <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" /> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <b><filter class="ch.qos.logback.core.filter.EvaluatorFilter"> - <evaluator name="myEval"> + <evaluator> <expression>event.getStatusCode() == 404</expression> </evaluator> - <onMismatch>NEUTRAL</onMismatch> - <onMatch>ACCEPT</onMatch> + <onMismatch>DENY</onMismatch> </filter></b> - <encoder> - <pattern> - %h %l %u %t %r %s %b - </pattern> - </encoder> + <encoder><pattern>%h %l %u %t %r %s %b</pattern></encoder> </appender> <appender-ref ref="STDOUT" /> </configuration></pre> - <p>We might imagine a slightly more complex use of filters to - ensure logging of 404 errors, except those returned on access to - CSS resources. Here is what such a configuration would look like: + <p>In the next example, we still log request resulting 404 errors, + except those requests asking for CSS files. </p> + <em>Example 6.10: Access Evaluator (logback-examples/src/main/java/chapters/filters/accessEventEvaluator2.xml)</em> <pre class="prettyprint source"><configuration> - + <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" /> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> - <b><filter class="ch.qos.logback.core.filter.EvaluatorFilter"> + <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> <evaluator name="Eval404"> - <expression>event.getStatusCode() == 404</expression> + <expression> + <b>(event.getStatusCode() == 404)</b> + <b>&amp;&amp;</b>  + <b>!(event.getRequestURI().contains(".css"))</b> + </expression> </evaluator> - <onMismatch>NEUTRAL</onMismatch> - <onMatch>ACCEPT</onMatch> + <onMismatch>DENY</onMismatch> </filter> - <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> - <evaluator name="EvalCSS"> - <expression>event.getRequestURI().contains("css")</expression> - </evaluator> - <onMismatch>NEUTRAL</onMismatch> - <onMatch>DENY</onMatch> - </filter></b> - <encoder> - <pattern> - %h %l %u %t %r %s %b - </pattern> - </encoder> + + <encoder><pattern>%h %l %u %t %r %s %b</pattern></encoder> </appender> <appender-ref ref="STDOUT" /> diff --git a/logback-site/src/site/pages/recipes/captureHttp.html b/logback-site/src/site/pages/recipes/captureHttp.html index 5e925fb..244478a 100644 --- a/logback-site/src/site/pages/recipes/captureHttp.html +++ b/logback-site/src/site/pages/recipes/captureHttp.html @@ -38,8 +38,8 @@ </p> <p>Certain Web-Service stacks can be easily configured to log - the SOAP traffic. For instance, with JBoss' Web-services stack, - you can set the level of the + SOAP traffic. For instance, with JBoss' Web-services stack, you + can set the level of the <code>org.jboss.ws.core.MessageTrace</code> logger to <code>TRACE</code> in order to enable SOAP message tracing as <a href="http://community.jboss.org/wiki/JBossWS-Log4j">documented @@ -48,7 +48,7 @@ <p>If you are using a different Web-Services stack, e.g. Metro, it might not be very convenient to enable SOAP message - tracing. In that case, and assuming you application is deployed + tracing. In that case, and assuming your application is deployed on Tomcat, you might want to enable <a href="http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Request_Dumper_F…">RequestDumperFilter</a>. Unfortunately, not only is <code>RequestDumperFilter</code> @@ -56,16 +56,16 @@ incoming request nor the outgoing response. </p> - <p>With help of logback-access and the <a - href="../access.html#teeFilter">TeeFilter</a> you can capture - the full input and output for each request as explained below. + <p>With the help of <a href="../access.html#teeFilter"> + logback-access its TeeFilter</a> you can capture the full input + and output for each request as explained below. </p> - <h3>Capturing</h3> + <h3><a name="capturing" href="#capturing">Capturing</a></h3> - <p>The <code>TeeFilter</code>, as any other servlet filter needs - to be declared in your web-application's <em>web.xml</em> + <p>The <code>TeeFilter</code>, as any other servlet filter, + needs to be declared in your web-application's <em>web.xml</em> file. Here is the decleration to add to your web-application's <em>web.xml</em> file. </p> @@ -97,14 +97,19 @@ <pre class="prettyprint source"><configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> - <layout class="ch.qos.logback.access.PatternLayout"> - <pattern>%fullRequest%n%n%fullResponse</pattern> - </layout> + <encoder> + <pattern><b>%fullRequest</b>%n%n<b>%fullResponse</b></pattern> + </encoder> </appender> <appender-ref ref="STDOUT" /> </configuration></pre> + <p>For the list of conversion words supported by logback-access' + <code>PatternLayout</code> please refer to <a + href="manual/layouts.html#AccessPatternLayout">its documentation</a>. + </p> + <p>Here is the output generated when accessing the <a href="../demo.html">logback-demo</a> application configured as shown above, yields:</p> @@ -141,8 +146,8 @@ Set-Cookie: JSESSIONID=bgebt99ce9om;path=/logback-demo <p> </p> - <h3>Disabling <code>TeeFilter</code> in the production - environment</h3> + <h3><a name="disabling" href="#disabling">Disabling + <code>TeeFilter</code> in the production environment</a></h3> <p>Due to its instrusive nature, <code>TeeFilter</code> can slow down performance. Moreover, altough we have fixed all currently @@ -168,19 +173,84 @@ Set-Cookie: JSESSIONID=bgebt99ce9om;path=/logback-demo <filter-class>ch.qos.logback.access.servlet.TeeFilter</filter-class> <init-param> <b></b> - <b><param-name>excludes</param-name></b> - <b><param-value>orion, gemini</param-value></b> + <param-name><b>excludes</b></param-name> + <param-value>orion, gemini</param-value> </init-param> </filter> </pre> - <p>If it is easier, you could also explicitly name the machines - of the integration envrionment in the includes list. + <p>If it is easier to exliclitly name the integration machines, + you could list them in the includes list and omit the excludes + list. </p> - <h3>Filtering captured requests</h3> + <h3><a name="filtering" href="#filtering">Filtering captured + requests</a></h3> - + <p>Let assume that our web-application is deployed in a + cluster. The cluster is located behind a load-balancer which + probes each member of the cluster once or twice a second to + check whether it is alive. Whenever a member becomes unavailable + the load-blancer will immediately (well, after at most one + second) divert traffic from that member. + </p> + + <p>While such a load-balancing strategy will ensure + high-availability of your web-applicaiton, it will also + seriously pollute the access-logs with the contents of each + probe made by the load-balancer. + </p> + + <p>We need to a way to filter-out these probes so that they are + no longer contaminate the log output. However, we need a way to + distinguish probes emanating from the load-balancer from other + requests that we deem desirable. The contents of the requests + can give you clues about possible criteria.</p> + + <p>Here is a sample probe as logged by logback-access:</p> + + <pre class="source"><b>HEAD</b> /myapp/<b>probe</b> HTTP/1.1 +connection: Close +host: 192.168.1.1 + +HTTP/1.1 200 OK +Expires: Thu, 01 Jan 1970 01:00:00 CET +X-Powered-By: Servlet 2.4; +Cache-Control: no-cache +Pragma: No-cache </pre> + + <p>From the above, we can see that the load-blancer probes use + the <a + href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4">HTTP + HEAD method</a> instead of the usual GET or POST. We can also + see that the request URI for the probes contains the string + "probe".</p> + + <p>Here is a <em>logback-access.xml</em> configuration file + which will deny any access event which uses the HEAD + method. Note that it is based on Janino.</p> + + <pre class="prettyprint source"><configuration> +  + <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" /> + + <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> + <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> +  + <evaluator> + <expression><b>event.getMethod().equals("HEAD")</b></expression> + </evaluator> + <onMismatch>NEUTRAL</onMismatch> + <onMatch>DENY</onMatch> + </filter> + + <encoder> + <pattern>%fullRequest%n%n%fullResponse</pattern> + </encoder> + </appender> + <appender-ref ref="STDOUT" /> +</configuration> </pre> <script src="../templates/footer.js" type="text/javascript"></script> </div> ----------------------------------------------------------------------- Summary of changes: .../java/chapters/filters/accessEventEvaluator.xml | 29 ++-- .../chapters/filters/accessEventEvaluator2.xml | 42 ++--- logback-site/src/site/pages/access.html | 50 +---- logback-site/src/site/pages/manual/filters.html | 215 +++++++++++++------- .../src/site/pages/recipes/captureHttp.html | 110 ++++++++-- .../images/chapters/filters/countingFilter.png | Bin 0 -> 89406 bytes 6 files changed, 275 insertions(+), 171 deletions(-) create mode 100644 logback-site/src/site/resources/manual/images/chapters/filters/countingFilter.png hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.25-38-g474f600
by git-noreply＠pixie.qos.ch 24 Nov '10

24 Nov '10

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Logback: the generic, reliable, fast and flexible logging framework.". The branch, master has been updated via 474f6003528b4f84583c148a9f9b98c014aa196c (commit) from f8db9f855682bca4c73856893ace329730ff7b9c (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=474f6003528b4f84583c148a… http://github.com/ceki/logback/commit/474f6003528b4f84583c148a9f9b98c014aa1… commit 474f6003528b4f84583c148a9f9b98c014aa196c Author: Ceki Gulcu <ceki(a)qos.ch> Date: Wed Nov 24 16:36:56 2010 +0100 minor edits diff --git a/logback-site/src/site/pages/access.html b/logback-site/src/site/pages/access.html index f81adaa..b0c3de9 100644 --- a/logback-site/src/site/pages/access.html +++ b/logback-site/src/site/pages/access.html @@ -549,9 +549,9 @@ Set-Cookie: JSESSIONID=bgebt99ce9om;path=/logback-demo code for test and production environments, <code>TeeFilter</code> supports <code>includes</code> and <code>excludes</code> parameters. <code>TeeFilter</code> will be active if the current host is listed - in the includes list and absent in the excludes list. An empty - includes list is interpreted as to contain all possible host names - in the universe. + in the includes list and absent in the excludes list. By special + convention, an empty includes list is interpreted as to contain all + possible host names in the universe. </p> <p>To enable <code>TeeFilter</code> only on the hosts named "orion" diff --git a/logback-site/src/site/pages/recipes/captureHttp.html b/logback-site/src/site/pages/recipes/captureHttp.html index 5e53d1b..5e925fb 100644 --- a/logback-site/src/site/pages/recipes/captureHttp.html +++ b/logback-site/src/site/pages/recipes/captureHttp.html @@ -141,15 +141,47 @@ Set-Cookie: JSESSIONID=bgebt99ce9om;path=/logback-demo <p> </p> - <p> + <h3>Disabling <code>TeeFilter</code> in the production + environment</h3> + + <p>Due to its instrusive nature, <code>TeeFilter</code> can slow + down performance. Moreover, altough we have fixed all currently + known bugs, <code>TeeFilter</code> has broken otherwise + correctly behaving applications in the past. Thus, while + extremely useful during problem hunting, we do not recommend + having <code>TeeFilter</code> active in production systems. In + order to avoid shipping different code for test and production + environments, <code>TeeFilter</code> supports includes and + excludes parameters. <code>TeeFilter</code> will be active if + the current host is listed in the includes list and absent in + the excludes list. By special convention, an empty + <em>includes</em> list is interpreted as to contain all possible + host names in the universe. + </p> + + <p>Assume we wish to capture HTTP traffic on all hosts except on + orion and gemini, the hostnames of the the production systems, + we would write:</p> + + <pre class="prettyprint source"><filter> + <filter-name>TeeFilter</filter-name> + <filter-class>ch.qos.logback.access.servlet.TeeFilter</filter-class> + <init-param> + <b></b> + <b><param-name>excludes</param-name></b> + <b><param-value>orion, gemini</param-value></b> + </init-param> +</filter> </pre> + + <p>If it is easier, you could also explicitly name the machines + of the integration envrionment in the includes list. </p> - - - <h3>Enabling only in the integration environment</h3> <h3>Filtering captured requests</h3> + + <script src="../templates/footer.js" type="text/javascript"></script> </div> </body> ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/access.html | 6 +- .../src/site/pages/recipes/captureHttp.html | 40 ++++++++++++++++++-- 2 files changed, 39 insertions(+), 7 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.25-37-gf8db9f8
by git-noreply＠pixie.qos.ch 22 Nov '10

22 Nov '10

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Logback: the generic, reliable, fast and flexible logging framework.". The branch, master has been updated via f8db9f855682bca4c73856893ace329730ff7b9c (commit) from 191fe722b5ef50af18600d94f6dfaa23eaf510f5 (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=f8db9f855682bca4c7385689… http://github.com/ceki/logback/commit/f8db9f855682bca4c73856893ace329730ff7… commit f8db9f855682bca4c73856893ace329730ff7b9c Author: Ceki Gulcu <ceki(a)qos.ch> Date: Mon Nov 22 19:21:57 2010 +0100 ow diff --git a/logback-site/src/site/pages/access.html b/logback-site/src/site/pages/access.html index 3a0055c..f81adaa 100644 --- a/logback-site/src/site/pages/access.html +++ b/logback-site/src/site/pages/access.html @@ -4,7 +4,7 @@ <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" /> - <title>Logback Access</title> + <title>Logback-access</title> <link rel="stylesheet" type="text/css" href="css/common.css" /> <link rel="stylesheet" type="text/css" href="css/screen.css" media="screen" /> <link rel="stylesheet" type="text/css" href="css/_print.css" media="print" /> @@ -19,7 +19,7 @@ </div> <div id="content"> - <h2>Access log with logback, Jetty and Tomcat</h2> + <h2>HTTP-access logs with logback-access, Jetty and Tomcat</h2> <div class="author"> Authors: Ceki Gülcü, Sébastien Pennec @@ -30,16 +30,17 @@ <h1>Introduction</h1> - <p>The logback-access module integrates with Servlet containers - such as Jetty or Tomcat to provide rich and powerful HTTP-access - log functionality. + <p>The logback-access module, part of the standard logback + distribution, integrates with Servlet containers such as Jetty or + Tomcat to provide rich and powerful HTTP-access log functionality. </p> <p>Logback was designed as a modular framework from the start. Making logback-core reusable under different circumstances without much recoding was one of our main goals. In accordance - with this strategy, logback-access builds on top of - logback-core. </p> + with this strategy, logback-access builds on top of logback-core + and can thus provide much of the functionality of logback-classic + but in the scope of HTPP-access logging. </p> <a name="tomcat"></a> <h1>Logback-access under Tomcat</h1> @@ -496,9 +497,9 @@ CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/mx4j-impl.jar</pre></div> <pre class="prettyprint source"><configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> - <layout class="ch.qos.logback.access.PatternLayout"> - <Pattern>%fullRequest%n%n%fullResponse</Pattern> - </layout> + <encoder> + <pattern>%fullRequest%n%n%fullResponse</pattern> + </encoder> </appender> <appender-ref ref="STDOUT" /> @@ -549,7 +550,7 @@ Set-Cookie: JSESSIONID=bgebt99ce9om;path=/logback-demo supports <code>includes</code> and <code>excludes</code> parameters. <code>TeeFilter</code> will be active if the current host is listed in the includes list and absent in the excludes list. An empty - includes list is interepreted as to contain all possible host names + includes list is interpreted as to contain all possible host names in the universe. </p> @@ -560,8 +561,8 @@ Set-Cookie: JSESSIONID=bgebt99ce9om;path=/logback-demo <filter-name>TeeFilter</filter-name> <filter-class>ch.qos.logback.access.servlet.TeeFilter</filter-class> <init-param> - <param-name>includes</param-name> - <param-value>orion, gemini</param-value> + <b><param-name>includes</param-name></b> + <b><param-value>orion, gemini</param-value></b> </init-param> </filter> </pre> @@ -572,8 +573,8 @@ Set-Cookie: JSESSIONID=bgebt99ce9om;path=/logback-demo <filter-name>TeeFilter</filter-name> <filter-class>ch.qos.logback.access.servlet.TeeFilter</filter-class> <init-param> - <param-name>excludes</param-name> - <param-value>orion, gemini</param-value> + <b><param-name>excludes</param-name></b> + <b><param-value>orion, gemini</param-value></b> </init-param> </filter> </pre> diff --git a/logback-site/src/site/pages/manual/configuration.html b/logback-site/src/site/pages/manual/configuration.html index 8d5bd64..ce31db1 100644 --- a/logback-site/src/site/pages/manual/configuration.html +++ b/logback-site/src/site/pages/manual/configuration.html @@ -1485,8 +1485,8 @@ fileName=myApp.log href="#definingPropsOnTheFly">Defining properties on the fly</a></h3> - <p>You may define properties from within the configuration file - using the <code><define></code> element. The define element takes + <p>You may define properties dynamically using the + <code><define></code> element. The define element takes two mandatory attributes: <span class="attr">name</span> and <span class="attr">class</span>. The <span class="attr">name</span> attribute designates the name of the property to set whereas the @@ -1494,8 +1494,8 @@ fileName=myApp.log implementing the <a href="../xref/ch/qos/logback/core/spi/PropertyDefiner.html">PropertyDefiner</a> interface. The value returned by the <code>getPropertyValue</code>() - method of the <code>PropertyDefiner</code> will be placed into the - named property. + method of the <code>PropertyDefiner</code> instance will be the + value of the named property. </p> <p>Here is an example.</p> diff --git a/logback-site/src/site/pages/recipes/captureHttp.html b/logback-site/src/site/pages/recipes/captureHttp.html new file mode 100644 index 0000000..5e53d1b --- /dev/null +++ b/logback-site/src/site/pages/recipes/captureHttp.html @@ -0,0 +1,157 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml"> + <head> + <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" /> + <title>Catpuring HTTP communications</title> + <link rel="stylesheet" type="text/css" href="../css/common.css" /> + <link rel="stylesheet" type="text/css" href="../css/screen.css" media="screen" /> + <link rel="stylesheet" type="text/css" href="../css/_print.css" media="print" /> + <link rel="stylesheet" type="text/css" href="../css/prettify.css" media="screen" /> + + </head> + <body onload="prettyPrint()"> + <script type="text/javascript">prefix='../';</script> + <script type="text/javascript" src="../js/prettify.js"></script> + <script src="../templates/header.js" type="text/javascript"></script> + <div id="left"> + <noscript>Please turn on Javascript to view this menu</noscript> + <script src="../templates/left.js" type="text/javascript"></script> + </div> + <div id="content"> + + <h2>Capturing incoming HTTP requests and outgoing responses</h2> + + <p>Logback ships with a module called logback-access which + integrates with Servlet containers such as Jetty or Tomcat to + provide rich and powerful HTTP-access log functionality. + </p> + + <p>When diagnosing issues in a web-application, it is very + helpful to be able to capture incoming HTTP requests and the + outgoing response. This is particularly true for a + web-applications offering web-services using <a + href="http://en.wikipedia.org/wiki/SOAP">SOAP</a>. Having access + to the "raw" SOAP message makes it much easier to diagnose + errors caused by misspelled namespaces or missing fields. + </p> + + <p>Certain Web-Service stacks can be easily configured to log + the SOAP traffic. For instance, with JBoss' Web-services stack, + you can set the level of the + <code>org.jboss.ws.core.MessageTrace</code> logger to + <code>TRACE</code> in order to enable SOAP message tracing as <a + href="http://community.jboss.org/wiki/JBossWS-Log4j">documented + in the Jboss wiki</a>. + </p> + + <p>If you are using a different Web-Services stack, e.g. Metro, + it might not be very convenient to enable SOAP message + tracing. In that case, and assuming you application is deployed + on Tomcat, you might want to enable <a + href="http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Request_Dumper_F…">RequestDumperFilter</a>. + Unfortunately, not only is <code>RequestDumperFilter</code> + rather hard to install, it does not dump the payload of the + incoming request nor the outgoing response. + </p> + + <p>With help of logback-access and the <a + href="../access.html#teeFilter">TeeFilter</a> you can capture + the full input and output for each request as explained below. + + </p> + + <h3>Capturing</h3> + + <p>The <code>TeeFilter</code>, as any other servlet filter needs + to be declared in your web-application's <em>web.xml</em> + file. Here is the decleration to add to your web-application's + <em>web.xml</em> file. + </p> + + <pre class="prettyprint source"><filter> + <filter-name>TeeFilter</filter-name> + <filter-class>ch.qos.logback.access.servlet.TeeFilter</filter-class> +</filter> + +<filter-mapping> + <filter-name>TeeFilter</filter-name> + <url-pattern>/*</url-pattern> +</filter-mapping></pre> + + <p>The <code>TeeFilter</code> requires the logback-access module + to be installed in your web-server. The installation of + logback-access is explained <a + href="../access.html">elsewhere</a>. Once you have installed + logback-access into your Servlet container, e.g. Tomcat or + Jetty, you can configure logback-access according to your wishes + with the help of a configuration file named + <em>logback-access.xml</em>. + </p> + + <p>Here is a sample <em>logback-access.xml</em> configuration + file which will output the full contents of the request and + response on the console. + </p> + + <pre class="prettyprint source"><configuration> + <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> + <layout class="ch.qos.logback.access.PatternLayout"> + <pattern>%fullRequest%n%n%fullResponse</pattern> + </layout> + </appender> + + <appender-ref ref="STDOUT" /> +</configuration></pre> + + <p>Here is the output generated when accessing the <a + href="../demo.html">logback-demo</a> application configured as shown + above, yields:</p> + + <p class="source"><b>GET /logback-demo/index.jsp HTTP/1.1</b> +Host: localhost:8080 +User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20070312 Firefox/1.5.0 +Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8 +Accept-Language: en-us,en;q=0.5 +Accept-Encoding: gzip,deflate +Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 +Keep-Alive: 300 +Connection: keep-alive +Referer: http://localhost:8080/logback-demo/login.jsp +Cookie: JSESSIONID=15c7tqi9ehlwk; OID324nkzcmr=null; OID32862zgoa=null; + + + +<b>HTTP/1.1 200 OK</b> +Content-Type: text/html; charset=iso-8859-1 +Expires: Thu, 01 Jan 1970 00:00:00 GMT +Set-Cookie: JSESSIONID=bgebt99ce9om;path=/logback-demo + + +<html> +<head> + <LINK REL=StyleSheet HREF="css/pk.css" /> +</head> +<body> + +<h2>Logback demo center</h2> + +[snip, so that text is reasonably sized]</p> + +<p> </p> + + <p> + </p> + + + <h3>Enabling only in the integration environment</h3> + + <h3>Filtering captured requests</h3> + + + <script src="../templates/footer.js" type="text/javascript"></script> + </div> + </body> +</html> + \ No newline at end of file diff --git a/logback-site/src/site/pages/recipes/index.html b/logback-site/src/site/pages/recipes/index.html index d2d24d5..84dc02b 100644 --- a/logback-site/src/site/pages/recipes/index.html +++ b/logback-site/src/site/pages/recipes/index.html @@ -29,9 +29,14 @@ <li><p><a href="emailPerTransaction.html">send an email per transaction but only for certain users</a></p></li> </ul> - </div> + <ul> + <li><p><a href="captureHttp.html">Capture incoming HTTP + requests and outgoing responses</a></p></li> + </ul> + </div> + <script src="../templates/footer.js" type="text/javascript"></script> </div> </body> ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/access.html | 31 ++-- .../src/site/pages/manual/configuration.html | 8 +- .../src/site/pages/recipes/captureHttp.html | 157 ++++++++++++++++++++ logback-site/src/site/pages/recipes/index.html | 7 +- 4 files changed, 183 insertions(+), 20 deletions(-) create mode 100644 logback-site/src/site/pages/recipes/captureHttp.html hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.25-36-g191fe72
by git-noreply＠pixie.qos.ch 21 Nov '10

21 Nov '10

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Logback: the generic, reliable, fast and flexible logging framework.". The branch, master has been updated via 191fe722b5ef50af18600d94f6dfaa23eaf510f5 (commit) from bb61e53367abe61a360118f4a43ca45390d06462 (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=191fe722b5ef50af18600d94… http://github.com/ceki/logback/commit/191fe722b5ef50af18600d94f6dfaa23eaf51… commit 191fe722b5ef50af18600d94f6dfaa23eaf510f5 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Sun Nov 21 21:18:44 2010 +0100 ongoing edits diff --git a/logback-site/src/site/pages/recipes/emailPerTransaction.html b/logback-site/src/site/pages/recipes/emailPerTransaction.html index 05aa27b..89e275d 100644 --- a/logback-site/src/site/pages/recipes/emailPerTransaction.html +++ b/logback-site/src/site/pages/recipes/emailPerTransaction.html @@ -24,39 +24,39 @@ <h2>Triggering an email containing the isoloated logs of selected transactions</h2> - <p>Let Dave and Tata be software engineers working at a company - called Fooware.com. As you might have guessed, Fooware.com sells - foos. Yes, foos. Let <em>Buscrit</em> be a business critical - back-end system running at Fooware.com. Buscrit is called by a - number of applications to make business-critical transactions of - various types. + <p>Let Dave and Carol be software QA engineers working at a + company called Fooware.com. As you might have guessed, + Fooware.com sells foos. Yes, foos. Let <em>Buscrit</em> be a + business critical back-end system running at + Fooware.com. Buscrit is called by a number of applications to + make business-critical transactions of various types. </p> - <p>We would like to allow Tata, a QA-engineer, to access the - logging data generated by Buscrit as conveniently as - possible. Tata could access the log files directly on the server - where Buscrit runs. Let us assume that accessing the log files - is impractical because one or ore more of the following - conditions holds true: + <p>We would like to allow Carol to access the logging data + generated by Buscrit as conveniently as possible. Carol could + access the log files directly on the server where Buscrit + runs. Let us assume that accessing the log files is somehow + impractical because one or ore more of the following conditions + holds true: </p> <ol> <li>Buscrit runs on multiple hosts and it is difficult to identify the host where a particular transaction was executed</li> - <li>Tata does not (or does not wish to) have access to the + <li>Carol does not (or does not wish to) have access to the hosts where Byscrit runs </li> - <li>Buscrit is tested by multiple testers simultanesouly so - that it is hard to indetify and track an individual - transaction in the log files + <li>Buscrit is tested by multiple testers, e.g. Dave and Carol + and others, simultanesouly so that it is hard to indetify and + track an individual transaction in the log files </li> </ol> <p>Given the above circumstances, let us create a logback - configuration so that Tata receives an email message at the end + configuration so that Carol receives an email message at the end of every transaction. We will iteratively refine this - configuration so that Tata will receive an email containing the + configuration so that Carol will receive an email containing the logs of each transaction in isolation and only for the transactions she explicitly selects. </p> @@ -68,11 +68,13 @@ href="../manual/appenders.html#SMTPAppender">appropriate section of the manual</a> to familiarize yourself with <code>SMTPAppender</code> and its properties. - </p> + </p> - <p>The logback-demo project ships with a Struts action, namely - PrimeAction, which can factorize integers. Here is the pertinent - structure of the code:</p> + <p>The <a href="demo.html">logback-demo</a> project contains a + Struts action called <a + href="http://logback-demo.qos.ch/xref/ch/qos/logback/demo/prime/PrimeAction.html"><code>PrimeAction</code></a>. It + can factorize integers. Here is the pertinent structure of + <code>PrimeAction</code>'s code:</p> <pre class="prettyprint source">package ch.qos.logback.demo.prime; @@ -109,19 +111,19 @@ public class PrimeAction extends Action { <p>In a real world application, a transaction would involve systems external to the application, e.g. a database or a - messaging queue. For the sake of simplicity, let us consider + messaging queue. For the sake of this example, let us consider each factorization request as a <em>transaciton</em>. At the end of each factorization request, i.e. each transaction, the logger of the <code>PrimeAction</code> instance is invoked with the SMTP_TRIGGER marker and the message "Prime computation - ended". Thus, we can capitalize on this logging request to - clarly identify the end of every transaction in order to trigger - an outgoing message. + ended". We can capitalize on this logging request to clearly + identify the end of every transaction in order to trigger an + outgoing message. </p> - <p>Here is a configuration file which uses JaninoEventEvaluator - to trigger an outgoing email for logging event marked with - SMTP_TRIGGER. + <p>Here is a configuration file which uses + <code>JaninoEventEvaluator</code> to trigger an outgoing email + for logging event marked with SMTP_TRIGGER. </p> <pre class="prettyprint @@ -150,6 +152,8 @@ public class PrimeAction extends Action { </root> </configuration></pre> + + <h3>Transaction isolation</h3> ----------------------------------------------------------------------- Summary of changes: .../site/pages/recipes/emailPerTransaction.html | 62 ++++++++++--------- 1 files changed, 33 insertions(+), 29 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[JIRA] Created: (LBCORE-182) FileAppender file property set in prudent mode example
by Antoine (JIRA) 19 Nov '10

19 Nov '10

FileAppender file property set in prudent mode example ------------------------------------------------------ Key: LBCORE-182 URL: http://jira.qos.ch/browse/LBCORE-182 Project: logback-core Issue Type: Bug Components: Other Affects Versions: 0.9.24 Environment: Jboss 4.0 JDK 1.5.0_21 Reporter: Antoine Assignee: Logback dev list Priority: Minor Hi, I think an error exists on your logback documentation. Indeed, the prudent mode description of the RollingFileAppender (http://logback.qos.ch/manual/appenders.html#RollingFileAppender) indicates the file property FileAppender should be left blank. However, in the logging separation page (http://logback.qos.ch/manual/loggingSeparation.html) the last example does not respect this rule : {quote} ... <appender name="FILE-${contextName}" class="ch.qos.logback.core.FileAppender"> <file>${contextName}.log</file> <prudent>true</prudent> ... {quote} How you an explaination ? Regards, Antoine -- 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 0

[JIRA] Created: (LBCLASSIC-233) Unable to loacte a pre configurated context file logback-<context-name>.xml in Glassfish.
by Jose Guerra (JIRA) 19 Nov '10

19 Nov '10

Unable to loacte a pre configurated context file logback-<context-name>.xml in Glassfish. ----------------------------------------------------------------------------------------- Key: LBCLASSIC-233 URL: http://jira.qos.ch/browse/LBCLASSIC-233 Project: logback-classic Issue Type: Sub-task Affects Versions: 0.9.26 Environment: Ubuntu 9.04, running on Core duo 2.33GHz, Glassfish 3.01, Java 6 and system property -Dlogback.ContextSelector=JNDI was set as well. Reporter: Jose Guerra Assignee: Logback dev list Having defined on my web.xml the JNDI context to locate my own logback configuration, logback is not able to locate the configuration file on WEB-INF/etc directory. As a workaround, I dropped the logback.xml file under WEB-INF/classes directory. <env-entry> <env-entry-name>logback/context-name</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>myapp</env-entry-value> </env-entry> <env-entry> <description>URL for configuring logback context</description> <env-entry-name>logback/configuration-resource</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>../etc/logback-myapp.xml</env-entry-value> </env-entry> -- 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 0

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.25-35-gbb61e53
by git-noreply＠pixie.qos.ch 17 Nov '10

17 Nov '10

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Logback: the generic, reliable, fast and flexible logging framework.". The branch, master has been updated via bb61e53367abe61a360118f4a43ca45390d06462 (commit) from 6d4fb9ec8008f6af55a0bc141221b46633510b7c (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=bb61e53367abe61a360118f4… http://github.com/ceki/logback/commit/bb61e53367abe61a360118f4a43ca45390d06… commit bb61e53367abe61a360118f4a43ca45390d06462 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Wed Nov 17 22:31:36 2010 +0100 ongoing work on the documentation diff --git a/logback-site/src/site/pages/access.html b/logback-site/src/site/pages/access.html index 6ae4543..3a0055c 100644 --- a/logback-site/src/site/pages/access.html +++ b/logback-site/src/site/pages/access.html @@ -8,11 +8,11 @@ <link rel="stylesheet" type="text/css" href="css/common.css" /> <link rel="stylesheet" type="text/css" href="css/screen.css" media="screen" /> <link rel="stylesheet" type="text/css" href="css/_print.css" media="print" /> - + <link rel="stylesheet" type="text/css" href="css/prettify.css" media="screen" /> </head> - <body> + <body onload="prettyPrint()"> <script type="text/javascript">prefix='';</script> - + <script type="text/javascript" src="js/prettify.js"></script> <script src="templates/header.js" type="text/javascript"></script> <div id="left"> <script src="templates/left.js" type="text/javascript"></script> @@ -44,23 +44,25 @@ <a name="tomcat"></a> <h1>Logback-access under Tomcat</h1> - <p>To use logback-access with Tomcat, after downloading the logback - distribution, place the files <em>logback-core-${project.version}.jar</em> - and <em>logback-access-${project.version}.jar</em> under - $TOMCAT_HOME/<b>server/lib/</b> directory, where $TOMCAT_HOME is - the folder where you have installed Tomcat. We have tested - logback-access with Tomcat versions 5.5.26 and 6.0.20. + <p>To use logback-access with Tomcat, after downloading the + logback distribution, place the files + <em>logback-core-${project.version}.jar</em> and + <em>logback-access-${project.version}.jar</em> under + $TOMCAT_HOME/lib/ directory, where $TOMCAT_HOME is the folder + where you have installed Tomcat. We have tested logback-access + with Tomcat version 6.0.20. </p> - <p>Place the logback-core and logback-access jars in +  <h2>LogbackValve</h2> @@ -77,7 +79,7 @@ add the following lines to the tomcat server configuration file, namely <em>$TOMCAT_HOME/conf/server.xml</em>: </p> - <div class="source"><pre><Valve className="ch.qos.logback.access.tomcat.LogbackValve"/></pre></div> + <pre class="source"><Valve className="ch.qos.logback.access.tomcat.LogbackValve"/></pre> <p>This line is usually nested within an <code><Engine></code> or <code><Host></code> element. @@ -112,8 +114,8 @@ the logback-access configuration file. Here is an example. </p> - <p class="source"><Valve className="ch.qos.logback.access.tomcat.LogbackValve" - quiet="true" filename="c:/my-logback-access.xml"/></p> + <pre class="prettyprint source"><Valve className="ch.qos.logback.access.tomcat.LogbackValve" + quiet="true" filename="c:/my-logback-access.xml"/></pre> <h3><a name="viewingStatusMessages" href="#viewingStatusMessages">Viewing status messages</a></h3> @@ -132,7 +134,7 @@ <p>To add this servlet to your web-application, add the following lines to its <em>WEB-INF/web.xml</em> file.</p> - <p class="source"> <servlet> + <pre class="prettyprint source"> <servlet> <servlet-name>AccessViewStatusMessages</servlet-name> <servlet-class>ch.qos.logback.access.ViewStatusMessagesServlet</servlet-class> </servlet> @@ -140,7 +142,7 @@ <servlet-mapping> <servlet-name>AccessViewStatusMessages</servlet-name> <url-pattern>/lbAccessStatus</url-pattern> - </servlet-mapping></p> + </servlet-mapping></pre> <p>The <code>ViewStatusMessages</code> servlet will available under the URL <code>http://host/yourWebapp/lbAccessStatus</code> @@ -180,13 +182,13 @@ jetty's main configuration file, namely <em>$JETTY_HOME/etc/jetty.xml</em>: </p> - <div class="source"><pre><Ref id="requestLog"> + <pre class="prettyprint source"><Ref id="requestLog"> <Set name="requestLog"> <New id="requestLogImpl" class="ch.qos.logback.access.jetty.RequestLogImpl"> </New> </Set> -</Ref></pre></div> +</Ref></pre> <p>By default, <code>RequestLogImpl</code> looks for a logback configuration file called <em>logback-access.xml</em>, in the same @@ -202,60 +204,61 @@ <em>logback-access.xml</em> configuration file. </p> - <div class="source"><pre><Ref id="requestLog"> + <pre class="prettyprint source"><Ref id="requestLog"> <Set name="requestLog"> <New id="requestLogImpl" class="ch.qos.logback.access.jetty.RequestLogImpl"> </New> <Set name="fileName">path/to/myaccess.xml</Set> </Set> -</Ref></pre></div> +</Ref></pre> <a name="configuration"></a> <h1>Logback-access configuration</h1> - <p>Although similar, the <em>logback-access.xml</em> file is slightly - different than its more common counterpart in logback-classic. - Appenders and Layouts are declared the exact same way. However, in - the access module there is no notion of loggers and consequently - logger elements are disallowed in logback-access configuration - files. + <p>Although similar, the format of <em>logback-access.xml</em> + configuration file is slightly different than the configuration file + format logback-classic. Appenders and Layouts are declared the + exact same way. However, in the access module there is no notion of + loggers and consequently logger elements are disallowed. </p> + <h3>Example 1: basic logback-access configuration</h3> <p> Here is a small but fully functional <em>logback-access.xml</em> configuration file: </p> -<div class="source"><pre><configuration> - <appender name="STDOUT" - class="ch.qos.logback.core.ConsoleAppender"> - <layout - class="ch.qos.logback.access.PatternLayout"> - <Pattern>%h %l %u %user %date "%r" %s %b</Pattern> - </layout> + <pre class="prettyprint source"><configuration> +  + <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" /> + + <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> + <encoder> + <pattern>%h %l %u %user %date "%r" %s %b</pattern> + </encoder> </appender> <appender-ref ref="STDOUT" /> -</configuration></pre></div> +</configuration></pre> <p> It declares a <code>ConsoleAppender</code> which prints its output - on the console. The <code>ConsoleAppender</code> contains a - <code>PatternLayout</code> object responsible to format this - output. The log format is specified by the "%h %l %u %user %date - "%r" %s %b" pattern which incidentally corresponds to Common Log - Format (CLF). This format is recognized by log analyzers such as - <a href="http://www.analog.cx/">Analog</a> or <a - href="http://awstats.sourceforge.net/">AWStats</a>. + on the console. The <code>ConsoleAppender</code> contains an + <code>Encoder</code> object responsible for formatting output. The + log format is specified by the "%h %l %u %user %date "%r" %s %b" + pattern which incidentally corresponds to the Common Log Format + (CLF). This format is recognized by log analyzers such as <a + href="http://www.analog.cx/">Analog</a> or <a + href="http://awstats.sourceforge.net/">AWStats</a>. </p> <p>The words "common" or "clf" are interpreted as shorthands for the said pattern. Thus, the following are all equivalent: </p> - <div class="source"><pre><Pattern>%h %l %u %user %date "%r" %s %b</Pattern> -<Pattern>common</Pattern> -<Pattern>clf</Pattern></pre></div> + <pre class="prettyprint source"><pattern>%h %l %u %user %date "%r" %s %b</pattern> +<pattern>common</pattern> +<pattern>clf</pattern></pre> <p>The so called "combined" format is also widely recognized. It is defined as the '%h %l %u %t "%r" %s %b "%i{Referer}" @@ -263,15 +266,15 @@ "combined" as a shorthand. Thus, the following directive </p> - <div class="source"><pre><layout class="ch.qos.logback.access.PatternLayout"> - <Pattern>%h %l %u %t "%r" %s %b "%i{Referer}" "%i{User-Agent}"</Pattern> -</layout></pre></div> + <pre class="prettyprint source"><encoder> + <pattern>%h %l %u %t "%r" %s %b "%i{Referer}" "%i{User-Agent}"</pattern> +</encoder></pre> <p>is equivalent to:</p> - <div class="source"><pre><layout class="ch.qos.logback.access.PatternLayout"> - <Pattern>combined</Pattern> -</layout></pre></div> + <pre class="prettyprint source"><encoder> + <pattern>combined</pattern> +</encoder></pre> <h3>Example 2: RollingFileAppender</h3> @@ -279,26 +282,27 @@ <p>The configuration file below configures a daily rolling <code>RollingFileAppender</code>. Note that due to the <em>.zip</em> suffix included in the value for <span - class="option">FileNamePattern</span> option, the log file are not + class="option">fileNamePattern</span> option, the log file are not only rolled daily, but they are also automatically compressed.</p> -<div class="source"><pre><configuration> - <appender name="FILE" - class="ch.qos.logback.core.rolling.RollingFileAppender"> - <File>access.log"</File> - <rollingPolicy - class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> - <FileNamePattern>access.%d{yyyy-MM-dd}.log.zip</FileNamePattern> + <pre class="prettyprint source"><configuration> +  + <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" /> + + <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> + <file>access.log</file> + <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> + <fileNamePattern>access.%d{yyyy-MM-dd}.log.zip</fileNamePattern> </rollingPolicy> - <layout class="ch.qos.logback.access.PatternLayout"> - <Pattern>combined</Pattern> - </layout> + <encoder> + <pattern>combined</pattern> + </encoder> </appender> <appender-ref ref="FILE" /> -</configuration></pre></div> +</configuration></pre> <p>These two examples should give you an idea of the possibilities offered by logback-access. In principle, most if not all of the @@ -344,7 +348,7 @@ CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.management.jmxremote.authenticate=false" Tomcat via the JConsole application, which can be started with the following command: </p> -<div class="source"><pre>jconsole</pre></div> + <pre class="source">jconsole</pre> <p>If you prefer MX4J to access your components via a web-based interface, here is a short summary of the steps to follow. After @@ -363,24 +367,21 @@ CATALINA_OPTS="$CATALINA_OPTS -Djavax.management.builder.initial=mx4j.server.MX4  CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/mx4j-impl.jar</pre></div> - <p> - Finally, declare a new <code>Connector</code> in the - <em>$TOMCAT_HOME/conf/server.xml</em> file: - </p> + <p>Finally, declare a new <code>Connector</code> in the + <em>$TOMCAT_HOME/conf/server.xml</em> file: </p> -<div class="source"><pre><Connector port="8050" + <pre class="prettyprint source"><Connector port="8050" handler.list="mx" mx.enabled="true" mx.httpHost="localhost" mx.httpPort="8082" - protocol="AJP/1.3" /></pre></div> + protocol="AJP/1.3" /></pre> - <p> - Once Tomcat is started, you should be able to reach your JMX + <p> Once Tomcat is started, you should be able to reach your JMX components by pointing your browser at the following URL: </p> -<div class="source"><pre>http://localhost:8082/</pre></div> + <pre class="source">http://localhost:8082/</pre> <h3>Configuring Jetty</h3> @@ -390,7 +391,7 @@ CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/mx4j-impl.jar</pre></div> added: </p> -<div class="source"><pre><Call id="MBeanServer" class="java.lang.management.ManagementFactory" name="getPlatformMBeanServer"/> + <pre class="prettyprint source"><Call id="MBeanServer" class="java.lang.management.ManagementFactory" name="getPlatformMBeanServer"/>  <Get id="Container" name="container"> <Call name="addEventListener"> @@ -402,12 +403,12 @@ CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/mx4j-impl.jar</pre></div> </New> </Arg> </Call> -</Get></pre></div> +</Get></pre> <p>Once Jetty is started with this configuration, all available components can be reviewed at: </p> -<div class="source"><pre>http://localhost:8082/</pre></div> + <pre class="prettyprint source">http://localhost:8082/</pre> <p>Logback-access' <code>RequestLogImpl</code> should be available, including its <code>start()</code> and @@ -427,43 +428,42 @@ CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/mx4j-impl.jar</pre></div> declare it, as any other filter: </p> -<div class="source"><pre><configuration> + <pre class="prettyprint source"><configuration> <b><filter class="ch.qos.logback.access.filter.CountingFilter"> <name>countingFilter</name> </filter></b> - <appender name="STDOUT" - class="ch.qos.logback.core.ConsoleAppender"> - <layout class="ch.qos.logback.access.PatternLayout"> - <Pattern>%h %l %u %t \"%r\" %s %b</Pattern> - </layout> + <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> + <encoder> + <pattern>%h %l %u %t \"%r\" %s %b</pattern> + </encoder> </appender> <appender-ref ref="STDOUT" /> -</configuration></pre></div> +</configuration></pre> - <p> - This component registers itself to the JMX server and publishes - the statistical data such as averages by minute, by hour, by - day, by week, and by month. Last month's, week's, day's, hour's - and minute's counts as well as the total number of access are - also exposed. + <p>This component registers itself to the JMX server and publishes + the statistical data such as averages by minute, by hour, by day, + by week, and by month. Last month's, week's, day's, hour's and + minute's counts as well as the total number of access are also + exposed. </p> - <h2><code>TeeFilter</code></h2> + <h2><a name="teeFilter" href="#teeFilter"><code>TeeFilter</code></a></h2> - <p>For debugging purposes, it is often handy to capture the client - request as well as the server response as is. The - <code>TeeFilter</code> was designed precisely for this purpose. - </p> + <p>In order to diagnose bugs in a web-application, it is often + handy to capture the client's request as well as the server's + response as is. The <code>TeeFilter</code> was designed precisely + for this purpose. + </p> - <p>The <code>TeeFilter</code> is a regular servlet filter. Like other - servlet filters, it needs to be declared in your web-application's - <em>web.xml</em> file: -</p> + <p>The <code>TeeFilter</code> is a regular servlet filter. Like other + servlet filters, it needs to be declared in your web-application's + <em>web.xml</em> file: + </p> -<div class="source"><filter> + <pre class="prettyprint source"><filter> <filter-name>TeeFilter</filter-name> <filter-class>ch.qos.logback.access.servlet.TeeFilter</filter-class> </filter> @@ -471,18 +471,16 @@ CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/mx4j-impl.jar</pre></div> <filter-mapping> <filter-name>TeeFilter</filter-name> <url-pattern>/*</url-pattern> -</filter-mapping> -</div> +</filter-mapping></pre> <p>We have tested <code>TeeFilter</code> to the best of our ability. However, since it duplicates the input stream of the request and the output stream of the response, it may interfere with - your application. For large input or output, it will add measurable - latency. Although we have already fixed all currently known bugs, - <code>TeeFilter</code> has broken otherwise correctly behaving - applications. Thus, in case of doubt, do not hesitate to disable - <code>TeeFilter</code>. - + your application. Moreover, for large input or output sizes, it will + add measurable latency. Although we have already fixed all currently + known bugs, <code>TeeFilter</code> has broken otherwise correctly + behaving applications in the past. Thus, in case of doubt, do not + hesitate to disable <code>TeeFilter</code>. </p> <p>Once <code>TeeFilter</code> is installed, the <a @@ -496,7 +494,7 @@ CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/mx4j-impl.jar</pre></div> output the full contents of the request and response on the console. </p> - <p class="source"><configuration> + <pre class="prettyprint source"><configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <layout class="ch.qos.logback.access.PatternLayout"> <Pattern>%fullRequest%n%n%fullResponse</Pattern> @@ -504,15 +502,16 @@ CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/mx4j-impl.jar</pre></div> </appender> <appender-ref ref="STDOUT" /> -</configuration></p> +</configuration></pre> - <p>Few clicks accessing the <a href="demo.html">logback-demo</a> - application configured as outlined above, yields:</p> + <p>Here is the output generated when accessing the <a + href="demo.html">logback-demo</a> application configured as shown + above, yields:</p> <p class="source"><b>GET /logback-demo/index.jsp HTTP/1.1</b> Host: localhost:8080 -User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11 -Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 +User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20070312 Firefox/1.5.0 +Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 @@ -542,6 +541,43 @@ Set-Cookie: JSESSIONID=bgebt99ce9om;path=/logback-demo <p> </p> + <p>As mentioned previously, while extremely useful during problem + hunting, <code>TeeFilter</code> can introduce new problems. + Consequently, we do not recommend having <code>TeeFilter</code> + active in production systems. In order to avoid shipping different + code for test and production environments, <code>TeeFilter</code> + supports <code>includes</code> and <code>excludes</code> parameters. + <code>TeeFilter</code> will be active if the current host is listed + in the includes list and absent in the excludes list. An empty + includes list is interepreted as to contain all possible host names + in the universe. + </p> + + <p>To enable <code>TeeFilter</code> only on the hosts named "orion" + and "gemini" and disabled elsewhere you would write:</p> + + <pre class="prettyprint source"><filter> + <filter-name>TeeFilter</filter-name> + <filter-class>ch.qos.logback.access.servlet.TeeFilter</filter-class> + <init-param> + <param-name>includes</param-name> + <param-value>orion, gemini</param-value> + </init-param> +</filter> </pre> + + <p>To enable <code>TeeFilter</code> on all hosts <em>except</em> + hosts named "orion" and "gemini" you would write:</p> + + <pre class="prettyprint source"><filter> + <filter-name>TeeFilter</filter-name> + <filter-class>ch.qos.logback.access.servlet.TeeFilter</filter-class> + <init-param> + <param-name>excludes</param-name> + <param-value>orion, gemini</param-value> + </init-param> +</filter> </pre> + + <script src="templates/footer.js" type="text/javascript"></script> </div> diff --git a/logback-site/src/site/pages/reasonsToSwitch.html b/logback-site/src/site/pages/reasonsToSwitch.html index cdb0b78..ed2bcd3 100644 --- a/logback-site/src/site/pages/reasonsToSwitch.html +++ b/logback-site/src/site/pages/reasonsToSwitch.html @@ -251,6 +251,18 @@ java.lang.Exception: 99 is invalid files older than 12 months will be automatically removed. </p> + + <h3><a name="logbackAccess" href="#logbackAccess">Logback-access, + i.e. HTTP-access logging with brains, is an integral part of + logback</a></h3> + + <p>Last but not least, the logback-access module, part of the + logback distribution, integrates with Servlet containers such as + Jetty or Tomcat to provide rich and powerful HTTP-access log + functionality. Since logback-access was part of the initial + design, all the logback-classic features you came love are + available in logback-access as well.</p> + <h3><a name="inSummary" href="#inSummary">In summary</a></h3> <p>We have listed a number of reasons for preferring logback over ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/access.html | 262 ++++++++++++---------- logback-site/src/site/pages/reasonsToSwitch.html | 12 + 2 files changed, 161 insertions(+), 113 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.25-34-g6d4fb9e
by git-noreply＠pixie.qos.ch 17 Nov '10

17 Nov '10

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Logback: the generic, reliable, fast and flexible logging framework.". The branch, master has been updated via 6d4fb9ec8008f6af55a0bc141221b46633510b7c (commit) from 67733e2544ada1403ad3c7420e1f17606e0c1f3a (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=6d4fb9ec8008f6af55a0bc14… http://github.com/ceki/logback/commit/6d4fb9ec8008f6af55a0bc141221b46633510… commit 6d4fb9ec8008f6af55a0bc141221b46633510b7c Author: Ceki Gulcu <ceki(a)qos.ch> Date: Wed Nov 17 17:43:25 2010 +0100 news about LBACCESS-15 diff --git a/logback-site/src/site/pages/news.html b/logback-site/src/site/pages/news.html index 3197d5a..136af2a 100644 --- a/logback-site/src/site/pages/news.html +++ b/logback-site/src/site/pages/news.html @@ -37,11 +37,16 @@ reported by Augusto Rodriguez. </p> + <p><code>TeeFilter</code> now takes include and exclude parameters + so that it can be enabled or disabled by host. This solves <a + href="http://jira.qos.ch/browse/LBACCESS-15">LBACCESS-15</a>.</p> + <p>Fixed <a href="http://jira.qos.ch/browse/LBCLASSIC-231">LBCLASSIC-231</a> as reported by Jeff Skjonsby. When configuring - SizeAndTimeBasedFNATP, <code>GaggerConfigurator</code> (Groovy) - will no longer throw a <code>NullPointerException</code>. + <code>SizeAndTimeBasedFNATP</code>, + <code>GaggerConfigurator</code> (Groovy) will no longer throw a + <code>NullPointerException</code>. </p> <p>Every context now returns its own name when asked for the @@ -50,8 +55,6 @@ requested by Michael Osipov. </p> - <p><code>TeeFilter</code> now takes include and exclude parameters - so that it can be enabled or disabled by host.</p> <h3>20th of October, 2010 - Release of version 0.9.26</h3> ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/news.html | 11 +++++++---- 1 files changed, 7 insertions(+), 4 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[JIRA] Resolved: (LBACCESS-15) TeeFilter should be disabled in productions systems
by Ceki Gulcu (JIRA) 17 Nov '10

17 Nov '10

[ http://jira.qos.ch/browse/LBACCESS-15?page=com.atlassian.jira.plugin.system… ] Ceki Gulcu resolved LBACCESS-15. -------------------------------- Fix Version/s: 0.9.27 Resolution: Fixed > TeeFilter should be disabled in productions systems > --------------------------------------------------- > > Key: LBACCESS-15 > URL: http://jira.qos.ch/browse/LBACCESS-15 > Project: logback-access > Issue Type: New Feature > Reporter: Ceki Gulcu > Assignee: Logback dev list > Fix For: 0.9.27 > > > Given that TeeFilter is part of web.xml it transpires into production which can be highly undesirable. > Example: > <filter> > <filter-name>TeeFilter</filter-name> > <filter-class>ch.qos.logback.access.servlet.TeeFilter</filter-class> > <init-param> > <param-name>ignoreOnHost</param-name> > <param-value>prodHost0, prodHost1</param-value> > </init-param> > </filter> -- 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 0

[JIRA] Created: (LBCORE-181) Memory issue caused by InfoStatus kept in StatusManager
by hefeng cui (JIRA) 17 Nov '10

17 Nov '10

Memory issue caused by InfoStatus kept in StatusManager -------------------------------------------------------- Key: LBCORE-181 URL: http://jira.qos.ch/browse/LBCORE-181 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.24, 0.9.25, 0.9.26 Environment: Linux, Reporter: hefeng cui Assignee: Logback dev list In my project, the RollingFileAppender was used with compression mechanism. Our application will generate lots of logs and then file rolling and compression will be triggered. We see the clear but slow trend of JVM's heap size increasement. By using the profiler tools to analysis the jvm memory, we saw there are lots of InfoStatus objects which keep increase with the number of file rolling. By looking at the source code, I found that StatusManager will keep those status forever if no explicit clear action invoked by api. Meantime, Compressor class will addStatus for each compression action. Then there is no way to garbage collect those InfoStatus. Below is the places where InfoStatus was created and added into StatusManager. ch.qos.logback.core.rolling.helper.Compressor public void compress(String nameOfFile2Compress, String nameOfCompressedFile) { switch (compressionMode) { case GZ: addInfo("GZ compressing [" + nameOfFile2Compress + "]."); gzCompress(nameOfFile2Compress, nameOfCompressedFile); break; case ZIP: addInfo("ZIP compressing [" + nameOfFile2Compress + "]."); zipCompress(nameOfFile2Compress, nameOfCompressedFile); break; case NONE: throw new UnsupportedOperationException( "compress method called in NONE compression mode"); } } If above analysis is correct, then I believe this will be a memory issue and it is a critical 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 4