November 2008 - logback-dev

svn commit: r1954 - in logback/trunk/logback-site/src/site: pages pages/css pages/manual resources/manual/images/chapter9
by noreply.ceki＠qos.ch 10 Nov '08

10 Nov '08

Author: ceki Date: Mon Nov 10 19:03:37 2008 New Revision: 1954 Added: logback/trunk/logback-site/src/site/pages/manual/jmxConfig.html - copied, changed from r1859, /logback/trunk/logback-site/src/site/pages/jmxConfig.html logback/trunk/logback-site/src/site/resources/manual/images/chapter9/ logback/trunk/logback-site/src/site/resources/manual/images/chapter9/jconsole15_jetty.gif (contents, props changed) logback/trunk/logback-site/src/site/resources/manual/images/chapter9/jconsole15_tomcat.gif (contents, props changed) logback/trunk/logback-site/src/site/resources/manual/images/chapter9/jmxConfigurator.gif (contents, props changed) logback/trunk/logback-site/src/site/resources/manual/images/chapter9/statusList.gif (contents, props changed) Removed: logback/trunk/logback-site/src/site/pages/jmxConfig.html Modified: logback/trunk/logback-site/src/site/pages/css/print.css logback/trunk/logback-site/src/site/pages/documentation.html logback/trunk/logback-site/src/site/pages/manual/architecture.html logback/trunk/logback-site/src/site/pages/manual/index_menu.js logback/trunk/logback-site/src/site/pages/news.html Log: - moved jmxConfig.html under manual/jmxConfig.html - updated chapter on JMX support - updated news.html - other minor changes in documentation Modified: logback/trunk/logback-site/src/site/pages/css/print.css ============================================================================== --- logback/trunk/logback-site/src/site/pages/css/print.css (original) +++ logback/trunk/logback-site/src/site/pages/css/print.css Mon Nov 10 19:03:37 2008 @@ -35,4 +35,17 @@ table.bodyTable th { vertical-align: text-top; text-align:center; -} \ No newline at end of file +} + + +.source { + background:#eee; + border-top: 1px solid #DDDDDD; + border-bottom: 1px solid #DDDDDD; + font-family: Courier, "MS Courier New", Prestige, Everson Monocourrier, monospace; + padding-bottom: 0.5ex; + padding-top: 0.5ex; + padding-left: 1ex; + white-space: pre; +} + Modified: logback/trunk/logback-site/src/site/pages/documentation.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/documentation.html (original) +++ logback/trunk/logback-site/src/site/pages/documentation.html Mon Nov 10 19:03:37 2008 @@ -40,10 +40,7 @@ <li> <a href="joran.html">Using Joran in your applications</a> </li> - - <li> - <a href="jmxConfig.html">How to use the logback JMX Configurator</a> - </li> + <li> <a href="demo.html">Walk-through logback-demo webApp</a> </li> @@ -69,13 +66,21 @@ <h2>Articles and Presentations</h2> <ul> + <li><a + href="http://ekkes-corner.blogspot.com/2008/10/index-blogseries-logging-in-osgi.h…">Logging + in OSGI Enterprise Applications</a>, by Ekkehard Gentz. + + </li> <li><a href="10reasons.ppt">Top 10 reasons for migrating to logback</a>, by Ceki Gülcü and Sébastien Pennec. </li> + + <li><a href="http://www.infoq.com/news/2007/08/logback">Logback: Evolving Java Logging</a> by Geoffrey Wiseman + </li> </ul> Modified: logback/trunk/logback-site/src/site/pages/manual/architecture.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/manual/architecture.html (original) +++ logback/trunk/logback-site/src/site/pages/manual/architecture.html Mon Nov 10 19:03:37 2008 @@ -153,7 +153,9 @@ </p> <div class="definition"> - <div class="deftitle">Level Inheritance</div> + <div class="deftitle"><a name="effectiveLevel" + href="#effectiveLevel">Effective Level (Level Inheritance)</a></div> + <p>The effective level for a given logger <em>L</em>, is equal to the first non-null level in its hierarchy, starting at <em>L</em> itself and proceeding upwards in the hierarchy Modified: logback/trunk/logback-site/src/site/pages/manual/index_menu.js ============================================================================== --- logback/trunk/logback-site/src/site/pages/manual/index_menu.js (original) +++ logback/trunk/logback-site/src/site/pages/manual/index_menu.js Mon Nov 10 19:03:37 2008 @@ -8,4 +8,4 @@ document.write('<p class="menu"><a href="filters.html"><b>Ch6: Filter chains</b></a>'); document.write('<p class="menu"><a href="mdc.html"><b>Ch7: Mapped Diagnostic Contexts</b></a>'); document.write('<p class="menu"><a href="contextSelector.html"><b>Ch8: Context Selectors</b></a>'); - +document.write('<p class="menu"><a href="jmxConfig.html"><b>Ch9: JMX Configurator</b></a>'); Copied: logback/trunk/logback-site/src/site/pages/manual/jmxConfig.html (from r1859, /logback/trunk/logback-site/src/site/pages/jmxConfig.html) ============================================================================== --- /logback/trunk/logback-site/src/site/pages/jmxConfig.html (original) +++ logback/trunk/logback-site/src/site/pages/manual/jmxConfig.html Mon Nov 10 19:03:37 2008 @@ -3,187 +3,280 @@ <head> <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" /> <title>JMX Configuration</title> -<link rel="stylesheet" type="text/css" media="screen" href="css/site.css" /> +<link rel="stylesheet" type="text/css" media="screen" href="../css/site.css" /> +<link rel="stylesheet" type="text/css" media="print" href="../css/print.css" /> + </head> <body> - <script> -prefix=''; -</script> - -<script src="templates/header.js"></script> -<div id="left"> - <script src="templates/left.js"></script> -</div> -<div id="content"> - - + <script> + prefix='../'; + </script> + <script src="../templates/header.js"></script> + <div id="left"> + <script src="../templates/left.js"></script> + </div> + <div id="right"> + <script src="index_menu.js"></script> + </div> + <div id="content"> <h2>JMX Configurator</h2> - <p>As of version 0.8, logback ships with a component that allows - configuration via JMX. Basically, it lets you reload the current - configuration, load a new one, list loggers and modify logger - levels. + <p>As its name indicates, <code>JMXConfigurator</code> allows + configuration of logback via JMX. In a nutshell, it lets you + reconfigure logback from the default configuration file, from a + designated file or URL, list loggers and modify logger levels. </p> - <h3>Configuring your server</h3> + <h3>Using the JMX Configurator</h3> + + + <p>If your server run on JDK 1.6 or later, then you can just + invoke <code>jconsole</code> application on the commmand line and + then connect to your server's MBeanServer. If you are running an + older JVM, then you should read the section on <a + href="jmxEnablingServer">JMX enabling your server</a>. + </p> - <p>The first step is to make sure that your application server - will allow the JMX Configurator to publish itself. In this - document, we'll cover the necessary steps in Tomcat and Jetty. + <p><code>JMXConfigurator</code> is enabled by a single line in + your logback configuration file, as shown below: </p> + +<div class="source"><pre><configuration> + <b><jmxConfigurator /></b> + + <appender name="console" class="ch.qos.logback.classic.ConsoleAppender"> + <layout class="ch.qos.logback.classic.PatternLayout"> + <Pattern>%date [%thread] %-5level %logger{25} - %msg%n</Pattern> + </layout> + </appender> + + <root> + <level value="debug"/> + <appender-ref ref="console" /> + </root> +</configuration></pre></div> - <h4>Configuring Tomcat</h4> + <p>After you connect to your server with <em>jconsole</em>, on the + MBeans panel, under "ch.qos.logback.classic.jmx.Configurator" + folder you should see several operations to choose from, as shown + in the figure below: + </p> - <p>Accessing JMX components with Tomcat requires to add the - following lines to the <em>$TOMCAT_HOME/bin/catalina.sh</em> - configuration file: - </p> + <img src="images/chapter9/jmxConfigurator.gif" alt="jmxConfigurator"/> + + <p>Thus, you can</p> -<div class="source"><pre>CATALINA_OPTS="-Dcom.sun.management.jmxremote" -CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.management.jmxremote.ssl=false" -CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.management.jmxremote.authenticate=false"</pre></div> + <ul> + <li>Reload logback configuration using the default configuration + file </li> - <p>Once started with these options, Tomcat's JMX compoenents can - be accessed with JConsole by issuing the following command in a - shell: - </p> -<div class="source"><pre>jconsole &</pre></div> + <li>Reload the configuration with the specified URL</li> + <li>Reload the configuration with the specified file</li> - <p>You might prefer to access your components via a web-based - solution using MX4J. In that case, here are the required steps: - </p> - - <p>First, <a href="http://mx4j.sourceforge.net/">download - MX4J</a>. Place the <em>mx4j-impl.jar</em> file in the - <em>$TOMCAT_HOME/bin/</em> directory, and the - <em>mx4j-tools.jar</em> in the <em>$TOMCAT_HOME/common/lib/</em> - directory. - </p> + <li>Set the level of a specified logger. To set to null, pass + the string "null" as value.</li> + <li>Get the level of a specified logger. Returned value can be + null.</li> + <li>Get the <a href="architecture.html#effectiveLevel">effective + level</a> of a specified logger</li> + </ul> - <p>Then, add the following lines to the - <em>$TOMCAT_HOME/bin/catalina.sh</em> configuration file: - </p> + <p><code>JMXConfigurator</code> exposes the list of existing + loggers and a status list as attributes.</p> + + <p>The status list can help you diagnose logbacks internal + state.</p> -<div class="source"><pre> -CATALINA_OPTS="-Dcom.sun.management.jmxremote" -CATALINA_OPTS="$CATALINA_OPTS -Djavax.management.builder.initial=mx4j.server.MX4JMBeanServerBuilder" + <img src="images/chapter9/statusList.gif" alt="statusList.gif"/> - -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: +  + + <h3> + <a name="jmxEnablingServer" href="#jmxEnablingServer">JMX enabling your + server</a> + </h3> + + <p>If your server runs with JDK 1.6 or later, your server should + be JMX enabled by default.</p> + + <p>For older JVMs, we suggest that you refer JMX-related + documentation of your web-server. Such documentation is available + for both <a + href="http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html">Tomcat</a> + and <a + href="http://docs.codehaus.org/display/JETTY/JMX">Jetty</a>. In + this document, we very briefly describe the required steps for + Tomcat and Jetty. </p> - -<div class="source"><pre><Connector port="8050" - handler.list="mx" - mx.enabled="true" - mx.httpHost="localhost" - mx.httpPort="8082" - protocol="AJP/1.3" /></pre></div> - - <p>Once Tomcat is started, you should be able to reach the JMX - components by pointing a browser to the following URL: - </p> -<div class="source"><pre>http://host_name:8082/</pre></div> +  - <h4>Configuring Jetty</h4> + <h4>Enabling JMX in Jetty (tested under JDK 1.5 and JDK 1.6)</h4> - <p>Configuring Jetty to publish JMX components requires a few - modifications to the <em>$JETTY_HOME/etc/jetty.xml</em> - configuration file. Here are the elements that need to be added: + <p>The following has been tested under JDK 1.5 and 1.6. Under JDK + 1.6 and later, your server is already JMX enabled by default and + you can, but do not need to, follow the steps discussed below. + Under JDK 1.5, adding JMX support in Jetty requires a number of + additions to the <em>$JETTY_HOME/etc/jetty.xml</em> configuration + file. Here are the elements that need to be added: </p> -<div class="source"><pre><Call id="MBeanServer" class="java.lang.management.ManagementFactory" name="getPlatformMBeanServer"/> - + <p class="source"><Call id="MBeanServer" class="java.lang.management.ManagementFactory" + name="getPlatformMBeanServer"/> + +<Get id="Container" name="container"> + <Call name="addEventListener"> + <Arg> + <New class="org.mortbay.management.MBeanContainer"> + <Arg><Ref id="MBeanServer"/></Arg> + <Call name="start" /> + </New> + </Arg> + </Call> +</Get> </p> + + <p>If you wish to access the MBeans exposed by Jetty with + jconsole, then you need start jetty with the + "com.sun.management.jmxremote" system property. + </p> + + <p>For a standalone version of Jetty, this translates to </p> + + + <p class="source">java <b>-Dcom.sun.management.jmxremote</b> -jar start.jar [config files]</p> + + <p>And if you wish to launch jetty as a Maven plugin, then you + need set the "com.sun.management.jmxremote" system property via + the <code>MAVEN_OPTS</code> shell variable, as follows + </p> + + <p class="source"><b>MAVEN_OPTS="-Dcom.sun.management.jmxremote</b>" +mvn jetty:run</p> + + <p>You can then access via <code>jconsole</code>.</p> + + <img src="images/chapter9/jconsole15_jetty.gif" alt="jconsole15_jetty.gif"/> + + <h4>MX4J with Jetty (tested under JDK 1.5 and 1.6)</h4> + + <p>Assuming you have already downloaded <a + href="http://mx4j.sourceforge.net/">MX4J</a>, you then need to + modify the jetty configuration file by adding an instruction to + set the management port. + </p> + + <p class="source"><Call id="MBeanServer" + class="java.lang.management.ManagementFactory" + name="getPlatformMBeanServer"/> + <Get id="Container" name="container"> <Call name="addEventListener"> <Arg> <New class="org.mortbay.management.MBeanContainer"> <Arg><Ref id="MBeanServer"/></Arg> - <Set name="managementPort">8082</Set> + <b><Set name="managementPort">8082</Set></b> <Call name="start" /> </New> </Arg> </Call> -</Get></pre></div> +</Get> + </p> + + <p>Moreover, <em>mx4j-tools.jar</em> needs to be added to Jetty's + class path. + </p> + + <p>If you are running jetty as a Maven plug-in, then you need to add + <em>mx4j-tools</em> as a dependency.</p> - <p>Once Jetty is started with this configuration, all available - components can be reviewed at this address: + <p class="source"><plugin> + <groupId>org.mortbay.jetty</groupId> + <artifactId>maven-jetty-plugin</artifactId> + <configuration> + <jettyConfig>path/to/jetty.xml</jettyConfig> + ... + </configuration> + <b><dependencies> + <dependency> + <groupId>mx4j</groupId> + <artifactId>mx4j-tools</artifactId> + <version>3.0.1</version> + </dependency> + </dependencies></b> +</plugin></p> + + <p>After Jetty is started with the above configuration, + <code>JMXConfigurator</code> will be available at the following + URL (search for "ch.qos.logback.classic"): </p> -<div class="source"><pre>http://host_name:8082/</pre></div> + <p class="source"><a href="http://localhost:8082/">http://localhost:8082/</a></p> - <h3>Using the JMX Configurator</h3> +  - <p>The next step is to declare the JMX Configurator in the logback - configuration file. This is done by adding a single element, as - shown below: + <h4>Configuring JMX for Tomcat (tested under JDK 1.5 and 1.6)</h4> + + <p>If you are using JDK 1.6 and later, your server is already JMX + enabled by default and you can, but do not need to, follow the + steps discussed below. Under JDK 1.5, Tomcat requires the addition + of the following lines to the + <em>$TOMCAT_HOME/bin/catalina.bat/sh</em> shell script: </p> + + <p class="source">CATALINA_OPTS="-Dcom.sun.management.jmxremote"</p> -<div class="source"><pre><configuration> + <p>Once started with these options, Tomcat's JMX compoenents can + be accessed with <code>jconsole</code> by issuing the following + command in a shell: + </p> + + <p class="source">jconsole</p> - <b><jmxConfigurator /></b> + <img src="images/chapter9/jconsole15_tomcat.gif" alt="jconsole15_tomcat.gif"/> - <appender name="console" class="ch.qos.logback.classic.ConsoleAppender"> - <layout class="ch.qos.logback.classic.PatternLayout"> - <Pattern>%date [%thread] %-5level %logger{25} - %msg%n</Pattern> - </layout> - </appender> - <root> - <level value="debug"/> - <appender-ref ref="console" /> - </root> -</configuration></pre></div> - - <p>Once the JMX Configurator is displayed on your screen, there - are several operations available. + <h4>MX4J with Tomcat</h4> + + <p>You might prefer to access JMX components via a web-based + interface provided by MX4J. In that case, here are the required + steps: </p> - <ul> - <li>Display the logback Status </li> + <p>Assuming you have already downloaded <a + href="http://mx4j.sourceforge.net/">MX4J</a>, placethe + <em>mx4j-tools.jar</em> file under the <em>$TOMCAT_HOME/bin/</em> + directory. Then, add the following lines to the + <em>$TOMCAT_HOME/bin/catalina.sh</em> configuration file: + </p> - <li>Reload the configuration using the same file that was previously - used. </li> + <p class="source"> +CATALINA_OPTS="-Dcom.sun.management.jmxremote" - <li>Reload the configuration using a file whose path is passed - as a parameter.</li> + +CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/mx4j-tools.jar</p> - <li>Reload the configuration using a file whose URL is passed as - a parameter.</li> + <p>Finally, declare a new <code>Connector</code> in the + <em>$TOMCAT_HOME/conf/server.xml</em> file: + </p> - <li>Get the level of a logger</li> - <li>Change the level setting of a specified logger.</li> - <li>Change a list of all declared loggers.</li> - <li>Change the level setting of a specified logger.</li> - </ul> - <p>In the last case, you must specify the name of the logger you - wish to alter, and its new level. - </p> + <p class="source"><Connector port="0" + handler.list="mx" + mx.enabled="true" + mx.httpHost="localhost" + mx.httpPort="8082" + protocol="AJP/1.3" /></p> + + <p>Once Tomcat is started, you should be able to find + JMXConfigurator by pointing your browser at the following URL + (search for "ch.qos.logback.classic"): + </p> + + <p class="source"><a href="http://localhost:8082">http://localhost:8082/</a></p> + - <p>The level of a logger is a value that can be null, if no - specific level has been configured for said logger. Its effective - level, on the other hand, is given with respect to the parent - loggers' levels. This value cannot be null, since all loggers are - direct or indirect children of the root logger, whose level is - always set. When trying to get the level or effective level of a - logger, the name of the logger has to be passed as a parameter. - Note that trying to get the level or effective level for a - nonexistent logger will not return any result. - </p> - - <p>Displaying logback status via JMX can help users check the - internal state of logback. It shows if anything has gone wrong, if - rollovers occured as expected, as well as other useful - information. It is also very useful when reloading a - configuration, since the user can immediately see if the - configuration file has been procsseds successfully. - </p> Modified: logback/trunk/logback-site/src/site/pages/news.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/news.html (original) +++ logback/trunk/logback-site/src/site/pages/news.html Mon Nov 10 19:03:37 2008 @@ -27,25 +27,71 @@ <h3>28th of November 2008 - Release of version 0.9.12</h3> + <p>Fixed <a href="http://jira.qos.ch/browse/LBCORE-26">bug + LBCORE-26</a> reported by Tsutomu YANO and independently by + Hontvári József and Gamaliel + Amaudruz. <code>RollingFileAppender</code> when used in conjunction + with <code>DateBasedRollingPolicy</code> will rollover existing log + files at initialization if their timestamp warrants it. + </p> + + <p>Fixed <a + href="http://jira.qos.ch/browse/LBCLASSIC-83">LBCLASSIC-83</a>. It + is now possible to set the level of a logger to null, even if it was + previously set to a non-null level. Previously, a + <code>NullPointerException</code> would be thrown. + </p> + + <p>In reponse to <a + href="http://jira.qos.ch/browse/LBCLASSIC-61">LBCLASSIC-61</a>, <a + href="http://jira.qos.ch/browse/LBCLASSIC-33">LBCLASSIC-33</a>, <a + href="http://jira.qos.ch/browse/LBCLASSIC-14">LBCLASSIC-24</a> and + <a href="http://jira.qos.ch/browse/LBCLASSIC-24">LBCLASSIC-14</a> + JMXConfigurator has been redesigned. + </p> + + <p>Fixed improvement request <a + href="http://jira.qos.ch/browse/LBCLASSIC-59">LBCLASSIC-59</a> + relation to StatusListeners, originally submitted by Anton Tagunov. + </p> + + <p>In response to <a href="http://jira.qos.ch/browse/LBCLASSIC-54"> + LBCLASSIC-54</a> support for turbo filters has refactored. The + present code is safe under concurrent access while still offering + good performance. + </p> + <p>Fixed <a href="http://jira.qos.ch/browse/LBCORE-43">LBCORE-43</a> reported by Bruno Navert. Configuration files can now look up property files from classpath resources. </p> + +  + <p>Fixed <a href="http://jira.qos.ch/browse/LBCLASSIC-69">bug LBCLASSIC-69</a> reported by Anton Tagunov. The LevelToSyslogSeverity now correctly handles the TRACE level. </p> <p>Fixed <a href="http://jira.qos.ch/browse/LBCLASSIC-57">bug - LBCLASSIC-57</a> reported by Anton Tagunov. + LBCLASSIC-57</a> reported by Anton Tagunov. SyslogAppender could + overwhelm the Syslog server with very large messages. SyslogAppender + now limits its message size to 256K. </p> - <p>Fixed <a - href="http://jira.qos.ch/browse/LBCLASSIC-59">improvement request - LBCLASSIC-59</a> orignally made by Anton Tagunov. + + <p>Fixed issue <a + href="http://jira.qos.ch/browse/LBCLASSIC-49">LBCLASSIC-49</a> + reported by Oliver Lietz. The getLogger() method in + <code>LoggerContext</code> class will now throw an + <code>IllegalArgumentException</code> when invoked with a null + argument. </p> + + + <hr width="80%" align="center" /> <h3>28th of October 2008 - Release of version 0.9.11</h3> @@ -196,6 +242,7 @@ contributed by Ralph Goers in <a href="http://jira.qos.ch/browse/LBCLASSIC-53">LBCLASSIC-53</a>. </p> + <hr width="80%" align="center" /> Added: logback/trunk/logback-site/src/site/resources/manual/images/chapter9/jconsole15_jetty.gif ============================================================================== Binary file. No diff available. Added: logback/trunk/logback-site/src/site/resources/manual/images/chapter9/jconsole15_tomcat.gif ============================================================================== Binary file. No diff available. Added: logback/trunk/logback-site/src/site/resources/manual/images/chapter9/jmxConfigurator.gif ============================================================================== Binary file. No diff available. Added: logback/trunk/logback-site/src/site/resources/manual/images/chapter9/statusList.gif ============================================================================== Binary file. No diff available.

1 0

Allowing Appenders to be attached to a Logger with a Level
by Robert Elliot 10 Nov '08

10 Nov '08

Hi all, Following a discussion on the Users list, I created a patch to logback-classic that allows an appender to be added to a Logger with a Level. Full details, including the patch and the use case that prompted me to do it, here: http://jira.qos.ch/browse/LBCLASSIC-82 Any thoughts? Thanks, Rob

1 0

[JIRA] Commented: (LBCLASSIC-46) ThrowableInformation should keep the Throwable cause hierarchy intact.
by Joern Huxhorn (JIRA) 08 Nov '08

08 Nov '08

[ http://jira.qos.ch/browse/LBCLASSIC-46?page=com.atlassian.jira.plugin.syste… ] Joern Huxhorn commented on LBCLASSIC-46: ---------------------------------------- Ceki, I don't mean to bug you but do you think that it would be possible to find a solution before a 0.9.12 release? At the moment, Lilith still requires the use of logback-0.9.9 because I don't want/have the time to implement the parsing of the Throwable... on the other hand, I'd really like to have a new release ready soon after 0.9.12 has been released. Unfortunately, I wasn't able to call you last week. I'm pretty occupied at the moment... > ThrowableInformation should keep the Throwable cause hierarchy intact. > ---------------------------------------------------------------------- > > Key: LBCLASSIC-46 > URL: http://jira.qos.ch/browse/LBCLASSIC-46 > Project: logback-classic > Issue Type: Improvement > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Joern Huxhorn > Assignee: Ceki Gulcu > Priority: Minor > > Instead of a String representation of the whole Throwable stack trace incl. cause ThrowableInformation should instead look like this: > public class ThrowableInformation implements Serializable > { > String throwableClassName; > String message; > StackTraceElement[] stackTrace; > ThrowableInformation cause; > } > I omitted get/set and private in this example. > StackTraceElement is perfectly Serializable and did also receive a public c'tor in Java 5 so I guess that the current ThrowableInformation is more or less a relict of log4j which had to stay compatible with older Java versions. > You could obviously keep the getThrowableStrRep() method for compatibility. > This bug is somewhat related to LBCLASSIC-45 because I think that ThrowableInformation should also, as LoggingEvent, be just a dumb data container with no real logic. > The logic to extract the relevant StackTraceElements should IMHO be moved either into Logger or into a static factory method of ThrowableInformation. -- 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-61) JMXConfigurationAction should allow a configurable ObjectName.
by Anders Engström (JIRA) 07 Nov '08

07 Nov '08

JMXConfigurationAction should allow a configurable ObjectName. -------------------------------------------------------------- Key: LBCLASSIC-61 URL: http://jira.qos.ch/browse/LBCLASSIC-61 Project: logback-classic Issue Type: Improvement Affects Versions: 0.9.9 Reporter: Anders Engström Assignee: Logback dev list Currently there is no way to customize the ObjectName the MBean is bound to (besides using a ContextSelector - which can be a hassle). This is an issue when deploying several applications in the same JVM (read: multiple web-applications in the same servlet engine). This patch modifies JMXConfiguratorAction to accept two additional attributes that allow customizing the ObjectName for the MBean: <jmxConfigurator/> This yields the default ObjectName of "ch.qos.logback.classic:Name=${nameOfContext},Type=ch.qos.logback.classic.jmx.Configurator". <jmxConfigurator namespace="foo"/> This results in "ch.qos.logback.classic:Name=${nameOfContext},Type=ch.qos.logback.classic.jmx.Configurator,Namespace=foo". <jmxConfigurator objectName="logback:name=foo,type=bar"/> Which obviously results in "logback:name=foo,type=bar" :) Let me know if I need to adjust the patch in any way. -- 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 3

svn commit: r1953 - in logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic: jmx joran/action
by noreply.ceki＠qos.ch 07 Nov '08

07 Nov '08

Author: ceki Date: Fri Nov 7 17:00:40 2008 New Revision: 1953 Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/jmx/JMXConfigurator.java logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/jmx/MBeanUtil.java logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/joran/action/JMXConfiguratorAction.java Log: Add support for a suffix attribute so as to distinguish the JMXConfigurator mbean of different web-application. This feature was requested in LBCLASSIC-61. If you have two web-apps, minimal and minimal other, the logback.xml config files relative to jmxConfigurator would look like: <configuration> <jmxConfigurator suffix="Webapp=minimal" /> ... </configuration> for the "minimal" web-app, and <configuration> <jmxConfigurator suffix="Webapp=minimalOther" /> ... </configuration> for the other web-app. You can choose other values for the suffix contents if you wish. For example, <jmxConfigurator suffix="Fruit=banana" /> is perfectly valid. To help with garbage collection, JMXConfigurator now will clear most if its internal fields. This is not strictly necessary but still helps with GC. Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/jmx/JMXConfigurator.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/jmx/JMXConfigurator.java (original) +++ logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/jmx/JMXConfigurator.java Fri Nov 7 17:00:40 2008 @@ -52,29 +52,34 @@ private static String EMPTY = ""; - final LoggerContext loggerContext; - final MBeanServer mbs; - final ObjectName objectName; - + LoggerContext loggerContext; + MBeanServer mbs; + ObjectName objectName; + String objectNameAsString; + + boolean started; @Override - protected void finalize() { - System.out.println("**************** JMXConfigurator finalized"); + public void finalize() { + System.out.println("....... finalize() "+this); } public JMXConfigurator(LoggerContext loggerContext, MBeanServer mbs, ObjectName objectName) { + System.out.println("....... constructor() "+this); + started = true; this.context = loggerContext; this.loggerContext = loggerContext; this.mbs = mbs; this.objectName = objectName; + this.objectNameAsString = objectName.toString(); removePreviousInstanceAsListener(); loggerContext.addListener(this); + } private void removePreviousInstanceAsListener() { List<LoggerContextListener> lcll = loggerContext.getCopyOfListenerList(); - for (LoggerContextListener lcl : lcll) { if (lcl instanceof JMXConfigurator) { JMXConfigurator jmxConfigurator = (JMXConfigurator) lcl; @@ -132,7 +137,6 @@ configurator.doConfigure(url); addInfo("Context: " + loggerContext.getName() + " reloaded."); } finally { - System.out.println("*************** printing"); StatusPrinter.print(statusListenerAsList.getStatusList()); } } @@ -219,30 +223,46 @@ * unregistered */ public void onReset(LoggerContext context) { + if(!started) { + addInfo("onReset() method called on a stopped JMXActivator [" + objectNameAsString + "]");; + } System.out.println("Unregistering JMXConfigurator"); + if (mbs.isRegistered(objectName)) { try { - addInfo("Unregistering mbean [" + objectName + "]"); + addInfo("Unregistering mbean [" + objectNameAsString + "]"); mbs.unregisterMBean(objectName); } catch (InstanceNotFoundException e) { // this is theoretically impossible - addError("Unable to find a verifiably registered mbean [" + objectName + addError("Unable to find a verifiably registered mbean [" + objectNameAsString + "]", e); } catch (MBeanRegistrationException e) { - addError("Failed to unregister [" + objectName + "]", e); + addError("Failed to unregister [" + objectNameAsString + "]", e); } } else { - addInfo("mbean [" + objectName + addInfo("mbean [" + objectNameAsString + "] was not in the mbean registry. This is OK."); } - + stop(); + } + + private void clearFields() { + System.out.println("Clearing fields"); + mbs = null; + objectName = null; + loggerContext = null; } + private void stop() { + started = false; + clearFields(); + } public void onStart(LoggerContext context) { + // nop } - @Override - public String toString() { - return this.getClass().getName() + "(" + context.getName() + ")"; - } +// @Override +// public String toString() { +// return this.getClass().getName() + "(" + context.getName() + ")"; +// } } Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/jmx/MBeanUtil.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/jmx/MBeanUtil.java (original) +++ logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/jmx/MBeanUtil.java Fri Nov 7 17:00:40 2008 @@ -51,8 +51,8 @@ try { MBeanServer mbs = ManagementFactory.getPlatformMBeanServer(); - JMXConfigurator jmxConfigurator = new JMXConfigurator(loggerContext, - mbs, objectName); + JMXConfigurator jmxConfigurator = new JMXConfigurator(loggerContext, mbs, + objectName); if (mbs.isRegistered(objectName)) { StatusUtil.addWarn(loggerContext, caller, @@ -67,11 +67,6 @@ return null; } } - - - - - public static void unregister(LoggerContext loggerContext, MBeanServer mbs, ObjectName objectName, Object caller) { @@ -82,10 +77,12 @@ mbs.unregisterMBean(objectName); } catch (InstanceNotFoundException e) { // this is theoretically impossible - e.printStackTrace(); + StatusUtil.addError(loggerContext, caller, "Failed to unregister mbean" + + objectName, e); } catch (MBeanRegistrationException e) { - // this also is theoretically impossible - e.printStackTrace(); + // this is theoretically impossible + StatusUtil.addError(loggerContext, caller, "Failed to unregister mbean" + + objectName, e); } } else { StatusUtil.addInfo(loggerContext, caller, "mbean [" + objectName Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/joran/action/JMXConfiguratorAction.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/joran/action/JMXConfiguratorAction.java (original) +++ logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/joran/action/JMXConfiguratorAction.java Fri Nov 7 17:00:40 2008 @@ -14,8 +14,10 @@ public class JMXConfiguratorAction extends Action { - static String OBJECT_NAME_ATTRIBUTE_NAME = "objectName"; - + static final String OBJECT_NAME_ATTRIBUTE_NAME = "objectName"; + static final String SUFFIX_ATTRIBUTE_NAME = "suffix"; + static final char JMX_NAME_SEPARATOR = ','; + @Override public void begin(InterpretationContext ec, String name, Attributes attributes) throws ActionException { @@ -24,6 +26,9 @@ String objectNameAsStr; String objectNameAttributeVal = attributes .getValue(OBJECT_NAME_ATTRIBUTE_NAME); + String suffixAttributeVal = attributes + .getValue(SUFFIX_ATTRIBUTE_NAME); + if (OptionHelper.isEmpty(objectNameAttributeVal)) { objectNameAsStr = MBeanUtil.getObjectNameFor((LoggerContext) context, JMXConfigurator.class); @@ -31,6 +36,13 @@ objectNameAsStr = objectNameAttributeVal; } + if(!OptionHelper.isEmpty(suffixAttributeVal)) { + if(suffixAttributeVal.indexOf(0) != JMX_NAME_SEPARATOR) { + objectNameAsStr += JMX_NAME_SEPARATOR; + } + objectNameAsStr += suffixAttributeVal; + } + ObjectName objectName = MBeanUtil.string2ObjectName(context, this, objectNameAsStr);

1 0

[JIRA] Resolved: (LBCLASSIC-14) jmxConfigurator - reload kills JMXBean
by Ceki Gulcu (JIRA) 07 Nov '08

07 Nov '08

[ http://jira.qos.ch/browse/LBCLASSIC-14?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu resolved LBCLASSIC-14. --------------------------------- Fix Version/s: 0.9.12 Resolution: Fixed > jmxConfigurator - reload kills JMXBean > -------------------------------------- > > Key: LBCLASSIC-14 > URL: http://jira.qos.ch/browse/LBCLASSIC-14 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Sebastian Davids > Assignee: Logback dev list > Fix For: 0.9.12 > > > add <jmxConfigurator /> to your configuration > add "-Dcom.sun.management.jmxremote" to your program args > open jconsole > invoke operation reload on ch.qos.logback.classic/default/ch.qos.logback.classic.jmx.Configuration > => bean will be removed from the MBean list but will not be re-added -- 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] Issue Comment Edited: (LBCLASSIC-33) unregistering in the jmx plugin
by Ceki Gulcu (JIRA) 07 Nov '08

07 Nov '08

[ http://jira.qos.ch/browse/LBCLASSIC-33?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu edited comment on LBCLASSIC-33 at 11/7/08 3:45 PM: -------------------------------------------------------------- Joern, After further investigation, I can see the previous instance of LoggerContext, created when the web-app is initialized, being finalized when the web-app is stopped. In practice, I have to invoke System.gc() from jconsole to provoke the garbage collection of the LoggerContext. As far as I can tell, the code in revision 1945 works well, as it should. Unfortunately, when I use the jmap/jhat tools for a very strange and unexplained reason, there still remains a reference to LoggerContext instance, which is extremely strange since I can guarantee that the only instance of LoggerContext created was garbage collected. I am attaching a copy of the jmap dump in case you'd like to have a look at it. At this stage, I am quite tempted to declare that the problem lies in jmap/jhat or alternatively my poor knowledge of those tools. was (Author: noreply.ceki(a)qos.ch) Joern, After further investigation, I can see the previous instance of LoggerContext, created when the web-app is initialized, being finalized when the web-app is stopped. In practice, I have to invoke System.gc() from jconsole to provoke the garbage collection of the LoggerContext. As far as I can tell, the code in revision 1945 works well, as it should. Unfortunately, when I use the jmap/jhat tools for a very strange and unexplained reason, there still remains a reference to LoggerContext instance, which is extremely strange since I can guarantee that the only instance of LoggerContext created was garbage collected. I am attaching a copy of the jmap dump in case you'd like to have a look at it. At this stage, I am quite tempted to declare that the problem lies in jmap/jhat or alternatively my poor knowledge of those tools. Joern, After further investigation, I can see the previous instance of LoggerContext, created when the web-app is initialized, being finalized when the web-app is stopped. In practice, I have to invoke System.gc() from jconsole to provoke the garbage collection of the LoggerContext. As far as I can tell, the code in revision 1945 works well, as it should. Unfortunately, when I use the jmap/jhat tools for a very strange and unexplained reason, there still remains a reference to LoggerContext instance, which is extremely strange since I can guarantee that the only instance of LoggerContext created was garbage collected. I am attaching a copy of the jmap dump in case you'd like to have a look at it. At this stage, I am quite tempted to declare that the problem lies in jmap/jhat or alternatively my poor knowledge of those tools. > unregistering in the jmx plugin > ------------------------------- > > Key: LBCLASSIC-33 > URL: http://jira.qos.ch/browse/LBCLASSIC-33 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Hontvári József > Assignee: Ceki Gulcu > > I started using the JMX plugin of login, and I wondered how should I > shut it down when a web application is restarted. I haven't found a > function which unregisters the Configurator MBean. This object holds a > reference (through ContextAwareBase) to a Context. I am afraid that not > unregistering it causes a memory leak when a web application is restarted. > There should be a way to shutdown the JMX plugin. Or more generally an API to shut down the Logback system in its entirety: flush buffers, close files etc. It must be decided what to do if a log request arrives when or after logback is shutting down. -- 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] Commented: (LBCLASSIC-33) unregistering in the jmx plugin
by Ceki Gulcu (JIRA) 07 Nov '08

07 Nov '08

[ http://jira.qos.ch/browse/LBCLASSIC-33?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu commented on LBCLASSIC-33: ------------------------------------- Joern, After further investigation, I can see the previous instance of LoggerContext, created when the web-app is initialized, being finalized when the web-app is stopped. In practice, I have to invoke System.gc() from jconsole to provoke the garbage collection of the LoggerContext. As far as I can tell, the code in revision 1945 works well, as it should. Unfortunately, when I use the jmap/jhat tools for a very strange and unexplained reason, there still remains a reference to LoggerContext instance, which is extremely strange since I can guarantee that the only instance of LoggerContext created was garbage collected. I am attaching a copy of the jmap dump in case you'd like to have a look at it. At this stage, I am quite tempted to declare that the problem lies in jmap/jhat or alternatively my poor knowledge of those tools. Joern, After further investigation, I can see the previous instance of LoggerContext, created when the web-app is initialized, being finalized when the web-app is stopped. In practice, I have to invoke System.gc() from jconsole to provoke the garbage collection of the LoggerContext. As far as I can tell, the code in revision 1945 works well, as it should. Unfortunately, when I use the jmap/jhat tools for a very strange and unexplained reason, there still remains a reference to LoggerContext instance, which is extremely strange since I can guarantee that the only instance of LoggerContext created was garbage collected. I am attaching a copy of the jmap dump in case you'd like to have a look at it. At this stage, I am quite tempted to declare that the problem lies in jmap/jhat or alternatively my poor knowledge of those tools. > unregistering in the jmx plugin > ------------------------------- > > Key: LBCLASSIC-33 > URL: http://jira.qos.ch/browse/LBCLASSIC-33 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Hontvári József > Assignee: Ceki Gulcu > > I started using the JMX plugin of login, and I wondered how should I > shut it down when a web application is restarted. I haven't found a > function which unregisters the Configurator MBean. This object holds a > reference (through ContextAwareBase) to a Context. I am afraid that not > unregistering it causes a memory leak when a web application is restarted. > There should be a way to shutdown the JMX plugin. Or more generally an API to shut down the Logback system in its entirety: flush buffers, close files etc. It must be decided what to do if a log request arrives when or after logback is shutting down. -- 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] Commented: (LBCLASSIC-55) Report URL config has been loaded from when debug="true"
by Henric Larsson (JIRA) 07 Nov '08

07 Nov '08

[ http://jira.qos.ch/browse/LBCLASSIC-55?page=com.atlassian.jira.plugin.syste… ] Henric Larsson commented on LBCLASSIC-55: ----------------------------------------- I would prefer to see the actual filepath the file is read from, including jar path if read from a jar. The reason is that it can be difficult to spot problems relating to multiple loback.xml or logback-test.xml in the classpath. > Report URL config has been loaded from when debug="true" > -------------------------------------------------------- > > Key: LBCLASSIC-55 > URL: http://jira.qos.ch/browse/LBCLASSIC-55 > Project: logback-classic > Issue Type: Improvement > Reporter: Anton Tagunov > Assignee: Ceki Gulcu > > Hi! > <configuration debug="true"> is nice. > It will be even nicer if it also reports what URL the config is being loaded from. > Thx! -- 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] Commented: (LBCLASSIC-57) SyslogAppender fails sporadically
by Henric Larsson (JIRA) 07 Nov '08

07 Nov '08

[ http://jira.qos.ch/browse/LBCLASSIC-57?page=com.atlassian.jira.plugin.syste… ] Henric Larsson commented on LBCLASSIC-57: ----------------------------------------- Hi Ceki, We've worked around this by writing a custom syslog appender that breaks long messages up in chunks to a configurable size. I think a hard limit is a bit too course, ideally it would be good to be able to configure the behaviour. I.e. truncate or chunk, and truncate/chunk limit. > SyslogAppender fails sporadically > --------------------------------- > > Key: LBCLASSIC-57 > URL: http://jira.qos.ch/browse/LBCLASSIC-57 > Project: logback-classic > Issue Type: Bug > Environment: $ uname -a > Linux ... 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:56:44 EST 2007 x86_64 x86_64 x86_64 GNU/Linux > $ java -version > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode) > multiprocessor PC box > Reporter: Anton Tagunov > Assignee: Logback dev list > > * several JVM-s per Linux box > * 5 SyslogAppender-s logging to syslog-ng on 127.0.0.1 > Once in a while one of the SyslogAppender-s (the busiest one with longest messages) stops logging completely > Other SyslogAppender-ss continue working fine. > /usr/sbin/tcpdump has confirmed upd packets reach > syslog-ng port via 'lo' network interface for remaining appends > /usr/sbin/tcpdump has confirmed NO udp packets reach > syslog-ng port via 'lo' network interface for the failing appender > We have JMX enabled. JConsole does show StatusManager messages. > There are no error messages there. > Just the messages emitted during initial logback configuration > from logback.xml on the classpath. > We had invoked 'reload()' method via JMX. > StatusMananger messages observed via JMX show that reload had happened. > Full re-configuration had happened. > All 5 SyslogAppenders had been apparently re-created. > Yet NO udp messages had come from the SyslogAppender > replacing those which had previously failed. > Reloading did not help 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 0