October 2009 - logback-dev - mailman3.qos.ch

branch, master, updated. 46070d291951284bb5ab647090b44f4aff4593b0
by git-noreply＠pixie.qos.ch 29 Oct '09

29 Oct '09

The branch, master has been updated via 46070d291951284bb5ab647090b44f4aff4593b0 (commit) from e72ea17ae0ed7a4d46a945be1eea1ab8ff9597dd (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=46070d291951284bb5ab6470… http://github.com/ceki/logback/commit/46070d291951284bb5ab647090b44f4aff459… commit 46070d291951284bb5ab647090b44f4aff4593b0 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Thu Oct 29 20:49:51 2009 +0100 - applied Charles' patch 9584cb96f17cad3222eca19c41ac171bb8056f9f dated October 22nd diff --git a/logback-site/src/site/pages/manual/layouts.html b/logback-site/src/site/pages/manual/layouts.html index 044c84a..18ac274 100644 --- a/logback-site/src/site/pages/manual/layouts.html +++ b/logback-site/src/site/pages/manual/layouts.html @@ -67,15 +67,13 @@ <h2>Logback-classic</h2> Logback-classic is wired to processes only events of type - <a href="../xref/ch/qos/logback/classic/spi/ILoggingEvent.html"> - <code>ch.qos.logback.classic.spi.ILoggingEvent</code></a>. This - fact will apparent for the remaining of this section. - + <a href="../xref/ch/qos/logback/classic/spi/ILoggingEvent.html"> + <code>ch.qos.logback.classic.spi.ILoggingEvent</code></a>. This + fact will be apparent throughout this section. <h3>Writing your own Layout</h3> - - Let us implement a simple yet functional layout for the + Let us implement a simple yet functional layout for the logback-classic module that prints the time elapsed since the start of the application, the level of the logging event, the caller thread between brackets, its logger name, a dash followed @@ -136,7 +134,7 @@ public class MySampleLayout extends LayoutBase<ILoggingEvent> { After adding these various characters to the string buffer, the - <code>doLayout()</code> method converts the buffer into + <code>doLayout()</code> method converts the buffer into a <code>String</code> and returns the resulting value. @@ -146,7 +144,7 @@ public class MySampleLayout extends LayoutBase<ILoggingEvent> { contents of exceptions as well. - <h3>Configuringyour custom layout</h3> + <h3>Configuring your custom layout</h3> Custom layouts are configured as any other layout. Here is as example: @@ -165,10 +163,11 @@ public class MySampleLayout extends LayoutBase<ILoggingEvent> { </root> </configuration></pre> - The sample application <a href="../xref/chapter5/SampleLogging.html"> - <code>chapter5.SampleLogging</code></a> configures logback with the - configuration script supplied as parameter and then logs a debug message, - followed by an error message. + The sample application <a + href="../xref/chapter5/SampleLogging.html"> + <code>chapter5.SampleLogging</code></a> configures logback with + the configuration script supplied as a parameter and then logs a + debug message, followed by an error message. To run this example issue the following command from within the @@ -197,7 +196,7 @@ public class MySampleLayout extends LayoutBase<ILoggingEvent> { </a> class contains two attributes. The first one is a prefix that can be added to the output. The second attribute is used to - choose wether to display the name of the thread from which + choose whether to display the name of the thread from which the logging request was sent. Here is the implementation of this class: @@ -347,20 +346,20 @@ WARN [main]: Message 2 conversion specifiers. In the example above, the conversion specifier %-5level means the level of the logging event should be left justified to a width of five characters. Format specifiers - will be explained in a short moment. + will be explained below. In PatternLayout, parenthesis can be used to group conversion patterns. It follows that the '(' and ')' carry special meaning and need to be escaped to be used as literals. Parentheses can be escaped by preceding the the opening and closing - parenthesis by backslash, but since backslash itself carries + parenthesis by a backslash, but since the backslash itself carries special meaning in Java, we need two backslashes, as in "\$" and "\$". Note that strictly speaking, only the closing parenthesis needs to be escaped to be used as a literal. - As mentionned previously, certain conversion specifiers can + As mentioned previously, certain conversion specifiers can include optional parameters which are passed between braces following the conversion word. A sample conversion specifier with options could be <code>%logger{10}</code>. Here "logger" is the @@ -464,15 +463,15 @@ WARN [main]: Message 2 </td> <td> - Used to output the fully qualified class name of the + Used to output the fully-qualified class name of the caller issuing the logging request. Just like the %logger conversion word above, - this word can take an interger as it's first option and use + this word can take an integer as its first option and use its abbreviation algorithm to shorten the class name. Zero - carries special meaning and w will cause the simple class - name to be output without its package name prefix. By - default the class name is output in full. + carries special meaning and will cause the simple class name + to be printed without its package name prefix. By default + the class name is printed in full. Generating the caller class information is not @@ -548,7 +547,7 @@ WARN [main]: Message 2 Generating the file information is not particularly fast. - Thus, it's use should be avoided unless execution speed is + Thus, its use should be avoided unless execution speed is not an issue. </td> @@ -561,36 +560,37 @@ WARN [main]: Message 2 </td> <td> - - Used to output location information of the - caller which generated the logging event. + Used to output location information of the caller which + generated the logging event. - - The location information depends on the JVM - implementation but usually consists of the fully - qualified name of the calling method followed by - the caller's source the file name and line - number between parentheses. + + The location information depends on the JVM + implementation but usually consists of the fully qualified + name of the calling method followed by the caller's source, + the file name and line number between parentheses. - - A integer can be added to the - caller - conversion specifier's options to configure the depth of - the information to be displayed. + + A integer can be added to the caller conversion + specifier's options to configure the depth of the + information to be displayed. - For example, %caller{2} would display the following excerpt: + + For example, %caller{2} would display the + following excerpt: -<div class="source white_bg"><pre>0 [main] DEBUG - logging statement +<pre class="source white_bg">0 [main] DEBUG - logging statement Caller+0 at mainPackage.sub.sample.Bar.sampleMethodName(Bar.java:22) -Caller+1 at mainPackage.sub.sample.Bar.createLoggingRequest(Bar.java:17)</pre></div> +Caller+1 at mainPackage.sub.sample.Bar.createLoggingRequest(Bar.java:17)</pre> + And %caller{3} would display this other excerpt: -<div class="source white_bg">16 [main] DEBUG - logging statement + +<pre class="source white_bg">16 [main] DEBUG - logging statement Caller+0 at mainPackage.sub.sample.Bar.sampleMethodName(Bar.java:22) Caller+1 at mainPackage.sub.sample.Bar.createLoggingRequest(Bar.java:17) -Caller+2 at mainPackage.ConfigTester.main(ConfigTester.java:38)</div> +Caller+2 at mainPackage.ConfigTester.main(ConfigTester.java:38)</pre> This conversion word can also use evaluators to test - logging events against a given criteria before creating the + logging events against a given criterion before creating the output. For example, using %caller{3, CALLER_DISPLAY_EVAL} will display three lines of stacktrace, only if the evaluator called @@ -598,9 +598,7 @@ Caller+2 at mainPackage.ConfigTester.main(ConfigTester.java:38)</div> answer. - Evaluators are described - further down this document. - + Evaluators are described below. </td> </tr> @@ -610,14 +608,13 @@ Caller+2 at mainPackage.ConfigTester.main(ConfigTester.java:38)</div> </td> <td> - - Used to output the line number from where the - logging request was issued. + Used to output the line number from where the logging + request was issued. - - Generating the line number information is not particularly fast. - Thus, it's use should be avoided unless - execution speed is not an issue. + + Generating the line number information is not particularly + fast. Thus, its use should be avoided unless execution + speed is not an issue. </td> </tr> @@ -628,8 +625,8 @@ Caller+2 at mainPackage.ConfigTester.main(ConfigTester.java:38)</div> m / msg / message </td> <td> - Used to output the application supplied message - associated with the logging event. + Used to output the application-supplied message associated + with the logging event. </td> </tr> @@ -804,9 +801,9 @@ Caller+2 at mainPackage.ConfigTester.main(ConfigTester.java:38)</div> </table> This conversion word can also use evaluators to test - logging events against a given criteria before creating the + logging events against a given criterion before creating the output. For example, using %ex{full, EX_DISPLAY_EVAL} - will display the full stacktrace of the exception, only if + will display the full stack trace of the exception, only if the evaluator called EX_DISPLAY_EVAL returns a negative answer. Evaluators are described further down in this document. @@ -1606,7 +1603,7 @@ public class TrivialMain { <a href="../xref/ch/qos/logback/classic/html/DefaultThrowableRenderer.html"> <code>DefaultThrowableRenderer</code></a> is assigned to each <code>HTMLLayout</code> instance. It writes exceptions on a - new table row, along with its stacktrace, in an easily + new table row, along with its stack trace, in an easily readable manner, as shown on the figure above. @@ -1736,7 +1733,7 @@ public class TrivialMain { <h3>Writing your own Layout</h3> Writing a custom <code>Layout</code> for logback access is - nearly identical as its sibling<code>Layout</code> in + nearly identical to its sibling<code>Layout</code> in logback-classic. @@ -1946,7 +1943,7 @@ public class TrivialMain { <code>HttpServletRequest</code> by a <a href="../xref/ch/qos/logback/access/servlet/TeeHttpServletRequest.html"> <code>TeeHttpServletRequest</code></a>. The latter object - allows access to the requet's <code>InputStream</code> + allows access to the request's <code>InputStream</code> multiple times without any loss of data. </td> @@ -1980,7 +1977,7 @@ public class TrivialMain { <td align="center">fullResponse</td> <td> This conversion word takes all the available data - associatede with the response, inclusing all headers of the + associated with the response, inclusing all headers of the response and response contents. </td> @@ -2041,12 +2038,6 @@ public class TrivialMain { <img src="images/htmlLayoutAccess.gif" alt="Access HTML Layout Sample Image"/> What can be better than a real world example? Our own log4j - properties to logback <a - href="http://logback.qos.ch/translator/">translator</a> makes use - of logback-access to showcase a live ouput, using a - <code>RollingFileAppender</code> and <code>HTMLLayout</code>. - - What can be better than a real world example? Our own log4j properties for logback <a href="http://logback.qos.ch/translator/">translator</a> makes use of logback-access to demonstrate live ouput from @@ -2061,12 +2052,6 @@ public class TrivialMain { this link</a>. - - - - - - <script src="../templates/footer.js" type="text/javascript"></script> </div> </body> ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/manual/layouts.html | 129 ++++++++++------------- 1 files changed, 57 insertions(+), 72 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

branch, master, updated. e72ea17ae0ed7a4d46a945be1eea1ab8ff9597dd
by git-noreply＠pixie.qos.ch 29 Oct '09

29 Oct '09

The branch, master has been updated via e72ea17ae0ed7a4d46a945be1eea1ab8ff9597dd (commit) from a2eb7c52b0312856e6f4c67670a4a11df4272780 (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=e72ea17ae0ed7a4d46a945be… http://github.com/ceki/logback/commit/e72ea17ae0ed7a4d46a945be1eea1ab8ff959… commit e72ea17ae0ed7a4d46a945be1eea1ab8ff9597dd Author: Ceki Gulcu <ceki(a)qos.ch> Date: Thu Oct 29 19:18:38 2009 +0100 - applied Charles patches upto an including 02d29034bbd38dd2a89741f096b1a77372ee5c5d dated October 20, 2009. diff --git a/logback-site/src/site/pages/css/common.css b/logback-site/src/site/pages/css/common.css index 1795ebc..2785f55 100644 --- a/logback-site/src/site/pages/css/common.css +++ b/logback-site/src/site/pages/css/common.css @@ -18,6 +18,10 @@ div.source { margin-top: 1em; } +.longline { + overflow: scroll; +} + .source, .command, .console { border-top: 1px solid #DDDDDD; border-bottom: 1px solid #DDDDDD; @@ -25,7 +29,6 @@ div.source { font-family: Courier, "MS Courier New", Prestige, monospace; padding-left: 1ex; white-space: pre; - overflow: scroll; } .source { diff --git a/logback-site/src/site/pages/manual/appenders.html b/logback-site/src/site/pages/manual/appenders.html index 18af54b..3051ea3 100644 --- a/logback-site/src/site/pages/manual/appenders.html +++ b/logback-site/src/site/pages/manual/appenders.html @@ -1147,11 +1147,11 @@ public interface RollingPolicy extends LifeCycle { ', '#' and '@' will appear in the resulting time text even when they are not enclosed within single quotes. Nevertheless, we recommend against using the colon - ":" character anywhere within the ':' character anywhere within the FileNamePattern option. The text before the colon is interpreted as the protocol specification of a URL, which - is most probably not what you intend. The forward-slash - "/" or backward slash "\" characters anywhere + is most probably not what you intend. The forward slash + '/' or backward slash '\' characters anywhere within the FileNamePattern property or within the date-and-time pattern will be interpreted as directory separators and any missing directories will be created as @@ -1182,7 +1182,7 @@ public interface RollingPolicy extends LifeCycle { file will be compressed to become /wombat/foo.2009-11-23.gz. For the 24th of November, logging output will be directed to - /wombat/folder/foo.2009-11-24 until its rolled over + /wombat/folder/foo.2009-11-24 until it's rolled over at the beginning of the next day. @@ -1264,7 +1264,7 @@ public interface RollingPolicy extends LifeCycle { <File>logFile.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>logFile.%d{yyyy-MM-dd}.log</FileNamePattern> -  +  <MaxHistory>30</MaxHistory> </rollingPolicy> @@ -1278,7 +1278,7 @@ public interface RollingPolicy extends LifeCycle { </root> </configuration></pre> - The next configuration sample illustrates the use + The next configuration sample illustrates the use of <code>RollingFileAppender</code> associated with <code>TimeBasedRollingPolicy</code> in Prudent mode. @@ -1311,7 +1311,7 @@ public interface RollingPolicy extends LifeCycle { href="#SizeAndTimeBasedFNATP">Size and time based archiving</a> </h3> - You may sometimes wish to archive files essentialy by date but + You may sometimes wish to archive files essentially by date but at the same time limit the size of each log file, in particular if post-processing tools impose size limits on the log files. In order to address this requirement, logback ships with a @@ -1357,8 +1357,8 @@ public interface RollingPolicy extends LifeCycle { Size and time based archiving supports cleaning of old archive files. You just need to specify the number of periods to preserve - with the <code><MaxHistory></code> element. When your - application is stopped and restarted, logging will continue at + within the <code><MaxHistory></code> element. When your + application is stopped and restarted, logging will continue at the correct location, i.e. at the largest index number for the current period. @@ -1475,8 +1475,8 @@ public interface TriggeringPolicy<E> extends LifeCycle { which implements the <code>ILoggingEvent</code> interface. Nevertheless, remote logging is non-intrusive as far as the logging event is concerned. On the receiving end after - de-serialization, the event can be logged as if it were generated - locally. Multiple <code>SocketAppender</code> instances running of + desrialization, the event can be logged as if it were generated + locally. Multiple <code>SocketAppender</code> instances running on different machines can direct their logging output to a central log server whose format is fixed. <code>SocketAppender</code> does not admit an associated layout because it sends serialized @@ -1496,7 +1496,7 @@ public interface TriggeringPolicy<E> extends LifeCycle { implementation. This means that if the link to server is slow but still faster than the rate of event production by the client, the client will not be affected by the slow network - connection. However, if the network connection is slower then the + connection. However, if the network connection is slower than the rate of event production, then the client can only progress at the network rate. In particular, in the extreme case where the network link to the server is down, the client will be eventually blocked. @@ -1589,7 +1589,7 @@ public interface TriggeringPolicy<E> extends LifeCycle { logged according to local server policy. The <code>SimpleSocketServer</code> application takes two parameters: port and configFile; where port is the port to listen on and - configFile is configuration script in XML format. + configFile is a configuration script in XML format. @@ -1675,7 +1675,7 @@ public interface TriggeringPolicy<E> extends LifeCycle { Allow us to repeat for emphasis that serialization of logging - events is not intrusive. A de-serialized event carries the same + events is not intrusive. A desrialized event carries the same information as any other logging event. It can be manipulated as if it were generated locally; except that serialized logging events by default do not include caller data. Here is an example @@ -1687,7 +1687,7 @@ public interface TriggeringPolicy<E> extends LifeCycle { src/main/java/chapter4/socket/server2.xml The configuration file server2.xml creates a - <code>ConsoleAppender</code> whose layout outputs the callers file + <code>ConsoleAppender</code> whose layout outputs the caller's file name and line number along with other information. If you run <code>SocketClient2</code> with the configuration file client1.xml as previously, you will notice that the output @@ -1720,7 +1720,7 @@ public interface TriggeringPolicy<E> extends LifeCycle { The <a href="../xref/ch/qos/logback/core/net/JMSAppenderBase.html"> - <code>JMSAppenderBase</code></a> subclasses conceptually accomplishes + <code>JMSAppenderBase</code></a> subclasses conceptually accomplish the same task as the <code>SocketAppender</code> but as the name suggests it is based on the JMS API instead of TCP sockets. JMS or the Java Message Service API @@ -1735,25 +1735,24 @@ public interface TriggeringPolicy<E> extends LifeCycle { to each other. - - The JMS specification provides for two types of messaging models, - publish-and-subscribe and point-to-point queuing. Logback supports the former - model with <code>JMSTopicAppender</code> and the latter with <code>JMSQueueAppender</code> - Both appenders extend the <code>JMSAppenderBase</code> class and - publish serialized events to a topic or queue specified by the user. + The JMS specification provides for two types of messaging + models, publish-and-subscribe and point-to-point queueing. Logback + supports the former model with <code>JMSTopicAppender</code> and + the latter with <code>JMSQueueAppender</code> Both appenders + extend the <code>JMSAppenderBase</code> class and publish + serialized events to a topic or queue specified by the user. - - One or more <code>JMSTopicSink</code> or - <code>JMSQueueSink</code> applications can register to a JMS - server and consume the serialized events. The consumer of JMS - appenders generated events need not be only - <code>JMSTopicSink</code> or <code>JMSQueueSink</code> - applications. Any application or MessageDrivenBean capable of - subscribing to the appropriate topic or queue and consuming - serialized logging event messages would be suitable. Additional - consumers could be quickly built based on the - <code>JMSTopicSink</code> or <code>JMSQueueSink</code> model. + One or more <code>JMSTopicSink</code> or + <code>JMSQueueSink</code> applications can register with a JMS + server and consume the serialized events. The consumers of events + generated by JMS appenders need not only be + <code>JMSTopicSink</code> or <code>JMSQueueSink</code> + applications. Any application or MessageDrivenBean capable of + subscribing to the appropriate topic or queue and consuming + serialized logging event messages would be suitable. Additional + consumers could be quickly built based on the + <code>JMSTopicSink</code> or <code>JMSQueueSink</code> model. @@ -1917,7 +1916,7 @@ public interface TriggeringPolicy<E> extends LifeCycle { naming server one would write: -<pre class="prettyprint source">Properties env = new Properties(); +<pre class="prettyprint source longline">Properties env = new Properties(); env.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.activemq.jndi.ActiveMQInitialContextFactory"); env.put(Context.PROVIDER_URL, "tcp://hostname:61616"); Context ctx = new InitialContext(env);</pre> @@ -1939,7 +1938,7 @@ Context ctx = new InitialContext(env);</pre> <h4>Comments on JMS appenders</h4> Transmitting a packet of information using JMS is certain to be - substantially slower then sending the same packet using raw TCP + substantially slower than sending the same packet using raw TCP sockets. JMS vendors bragging about the performance of their messaging platform tend to omit this simple fact. Guaranteed store and forward messaging comes at a hefty price. In return for @@ -1954,8 +1953,8 @@ Context ctx = new InitialContext(env);</pre> delivery mode instructs the JMS provider to log the message to stable storage as part of the client's send operation, allowing the message to survive provider crashes. JMS appenders do not set - the delivery mode of messages it produces because according to the - JMS specification, the delivery mode is considered as an + the delivery mode of messages they produce because according to + the JMS specification, the delivery mode is considered as an administered property. @@ -2195,7 +2194,7 @@ Context ctx = new InitialContext(env);</pre> href="../xref/ch/qos/logback/classic/net/SMTPAppender.html"><code>SMTPAppender</code></a> accumulates logging events in a fixed-size buffer and sends them in an email after a user-specified event occurs. By default, the - email transmission is -triggered by a logging event of level ERROR + email transmission is triggered by a logging event of level ERROR or higher. @@ -2465,10 +2464,10 @@ Context ctx = new InitialContext(env);</pre> "View→Message Body As→Original HTML" option must be set. Yahoo!Mail's support for HTML email, in particular its CSS support is very good. GMail on the other hand, while it - honors the basic HTML table structure, it ignores the internal-CSS - formatting. Gmail supports inline-CSS formatitng but since - inline-CSS would make the resulting output too voluminous, - <code>HTMLLayout</code> does not use inline-CSS. + honors the basic HTML table structure, ignores the internal-CSS + formatting. Gmail supports inline CSS formatitng but since inline + CSS would make the resulting output too voluminous, + <code>HTMLLayout</code> does not use inline CSS. <h3>Triggering event</h3> @@ -2649,7 +2648,7 @@ public class CounterBasedEvaluator extends ContextAwareBase implements EventEval These three tables are logging_event, logging_event_property and - logging_event_exception. They all must exist before + logging_event_exception. They must exist before <code>DBAppender</code> can be used. Logback ships with SQL scripts that will create the tables. They can be found in the found in the @@ -2664,7 +2663,8 @@ public class CounterBasedEvaluator extends ContextAwareBase implements EventEval If your JDBC driver supports the <code>getGeneratedKeys</code> method introduced in JDBC 3.0 specification, assuming you have created the appropriate database tables as mentioned above, then - no more steps are required, excluding usual logback configuration. + no more steps are required, excluding the usual logback + configuration. Otherwise, there must be an <code>SQLDialect</code> appropriate @@ -2741,23 +2741,21 @@ public class CounterBasedEvaluator extends ContextAwareBase implements EventEval Experiments show that writing a single event into the database takes approximately 10 milliseconds, on a "standard" PC. If pooled connections are used, this figure drops to around 1 - milliseconds. Note that most JDBC drivers already ship with + millisecond. Note that most JDBC drivers already ship with connection pooling support. - - Configuring logback to use <code>DBAppender</code> can be done - in several different ways, depending on the tools one has to - connect to the database, and the database itself. All manners of - configuring <code>DBAppender</code> are about setting its - <code>ConnectionSource</code> object, which we will cover in - a short moment. + Configuring logback to use <code>DBAppender</code> can be done + in several different ways, depending on the tools one has to + connect to the database, and the database itself. The key issue in + configuring <code>DBAppender</code> is about setting its + <code>ConnectionSource</code> object, as we shall discover + shortly. - - Once logback is configured properly, the logging events are sent to - the specified database. As stated previously, there are three tables - used by logback to store logging event data. + Once logback is configured properly, the logging events are + sent to the specified database. As stated previously, there are + three tables used by logback to store logging event data. @@ -2770,16 +2768,18 @@ public class CounterBasedEvaluator extends ContextAwareBase implements EventEval <th>Description</th> </tr> <tr class="b"> - <td>timestmp</td> + <td>timestamp</td> <td><code>big int</code></td> <td>The timestamp that was valid at the logging event's creation.</td> </tr> <tr class="a"> <td>formatted_message</td> <td><code>text</code></td> - <td>The message that has been added to the logging event, after formatting with - <code>org.slf4j.impl.MessageFormatter</code>, in case object were passed - along with the message.</td> + + <td>The message that has been added to the logging event, + after formatting with + <code>org.slf4j.impl.MessageFormatter</code>, in case objects + were passed along with the message.</td> </tr> <tr class="b"> <td>logger_name</td> @@ -2795,17 +2795,18 @@ public class CounterBasedEvaluator extends ContextAwareBase implements EventEval <td>reference_flag</td> <td><code>smallint</code></td> <td> - - This field is used by logback to identify logging events that - have an exception or <code>MDC</code>property values associated. + This field is used by logback to identify logging events + that have an exception or <code>MDC</code>property values + associated. - - It's value is computed by - <code>ch.qos.logback.classic.db.DBHelper</code>. A logging event that - contains <code>MDC</code> or <code>Context</code> - properties has a flag number of 1. One - that contains an exception has a flag number of 2. A logging - event that contains both elements has a flag number of 3. + + Its value is computed by + <code>ch.qos.logback.classic.db.DBHelper</code>. A logging + event that contains <code>MDC</code> or <code>Context</code> + properties has a flag number of 1. One that + contains an exception has a flag number of 2. A + logging event that contains both elements has a flag number + of 3. </td> </tr> @@ -2913,7 +2914,7 @@ public class CounterBasedEvaluator extends ContextAwareBase implements EventEval <h4>ConnectionSource</h4> The <code>ConnectionSource</code> interface provides a - pluggable means of transparently obtaining JDBC Connections for + pluggable means of transparently obtaining JDBC connections for logback classes that require the use of a <code>java.sql.Connection</code>. There are currently three implementations of <code>ConnectionSource</code>, namely @@ -3141,7 +3142,7 @@ public class CounterBasedEvaluator extends ContextAwareBase implements EventEval With this configuration file, sending 500 logging events to a MySQL database takes a whopping 5 seconds, that is 10 milliseconds - per requests. This figure is unacceptable when dealing with large + per request. This figure is unacceptable when dealing with large applications. @@ -3174,9 +3175,9 @@ public class CounterBasedEvaluator extends ContextAwareBase implements EventEval </configuration></pre> With this new configuration, sending 500 logging requests to - the same MySQL database as previously used takes around 0.5 - seconds, for an average time of 1 millisecond per request. The - gain is a 10 factor. + the aforementioned MySQL database around 0.5 seconds, for an + average time of 1 millisecond per request, i.e. equivalent to a + tenfold improvement in performance. <h3><a name="SyslogAppender" @@ -3259,7 +3260,7 @@ public class CounterBasedEvaluator extends ContextAwareBase implements EventEval </td> <td> The SuffixPattern option - specifies the format of the non-standardized part the + specifies the format of the non-standardized part of the message sent to the syslog server. By default, its value is [%thread] %logger %msg. Any value that a <code>PatternLayout</code> could use is a correct SiftingAppender</code> definition itself. By default, <code>SiftingAppender</code> uses MDC key/value pairs as - a discriminatorg. + a discriminator. After configuring logback, the <a @@ -3395,7 +3396,7 @@ logger.debug("Alice says hello"); will be automatically closed and discarded. - It is not enough to have different appender instances, each + It is not enough to have different appender instances; each instance must output to a distinct target resource. To allow such differentiation, within the nested appender (FileAppender above), the key passed to the discriminator, "userid" in the above @@ -3405,7 +3406,7 @@ logger.debug("Alice says hello"); used by a given nested appender. - Running <code>SiftExample</code> application with the + Running the <code>SiftExample</code> application with the "byUserid.xml" configuration file shown above, will result in two distinct log files, "unknown.log" and "Alice.log". @@ -3417,16 +3418,16 @@ logger.debug("Alice says hello"); You can easily write your appender by sub-classing <code>AppenderBase</code>. It handles support for filters, status - among other functionality shared by most appenders. The derived - class only needs to implement one method, namely + messages and other functionality shared by most appenders. The + derived class only needs to implement one method, namely <code>append(Object eventObject)</code>. The <code>CountingConsoleAppender</code>, which we list next, appends a limited number of incoming events on the console. It shuts down after the limit is reached. It uses a - <code>Layout</code> to format the events and accepts a parameter, - thus a few more methods are needed. + <code>Layout</code> to format the events and accepts a parameter. + Thus, a few more methods are needed. Example 4.: @@ -3484,16 +3485,15 @@ public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> { fails to start with an error message. - This custom appender illustrates a two points: - + This custom appender illustrates two points: <ul> <li>All properties that follow the setter/getter JavaBeans conventions are handled transparently. The <code>start()</code> method, which is called automatically during logback - configuration, has the responsibility to verify that the various - properties of the appender are coherent. + configuration, has the responsibility of verifying that the + various properties of the appender are coherent. </li> <li>The <code>AppenderBase.doAppend()</code> method invokes the @@ -3531,7 +3531,7 @@ public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> { entity by transmitting serialized <code>AccessEvent</code> objects over the wire. Remote logging is non-intrusive as far as the access event is concerned. On the receiving end after - de-serialization, the event can be logged as if it were generated + desrialization, the event can be logged as if it were generated locally. @@ -3571,12 +3571,11 @@ public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> { <To>recipient_email(a)host.com</To> </appender></pre> - - This way of triggering the email lets user select pages that are important steps - in a specific process, for example. - When such a page is accessed, the email is sent with the pages - that were accessed previously, and any information the user wants to be included - in the email. + This way of triggering the email lets users select pages that + are important steps in a specific process, for example. When such + a page is accessed, the email is sent with the pages that were + accessed previously, and any information the user wants to be + included in the email. @@ -3588,16 +3587,18 @@ public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> { <a href="../xref/ch/qos/logback/access/db/DBAppender.html"><code>DBAppender</code></a> is used to insert the access events into a database. - - Two tables are used by <code>DBAppender</code>: access_event and - access_event_header. They all must exist before <code>DBAppender</code> - can be used. Logback ships with SQL scripts that will create the tables. - They can be found in the found in the - logback-access/src/main/java/ch/qos/logback/access/db/dialect directory. There - is a specific script for each of the most popular database systems. - If the script for your particular type of database system is missing, it should be - quite easy to write one, taking example on the already existing scripts. If - you send them to us, we will gladly include missing scripts in future releases. + + Two tables are used by <code>DBAppender</code>: + access_event and access_event_header. They all + must exist before <code>DBAppender</code> can be used. Logback + ships with SQL scripts that will create the tables. They can be + found in the + logback-access/src/main/java/ch/qos/logback/access/db/dialect + directory. There is a specific script for each of the most popular + database systems. If the script for your particular type of + database system is missing, it should be quite easy to write one, + taking as example existing scripts. If you send them to us, we + will gladly include missing scripts in future releases. The access_event table's fields are described below: @@ -3609,7 +3610,7 @@ public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> { <th>Description</th> </tr> <tr class="a"> - <td>timestmp</td> + <td>timestamp</td> <td><code>big int</code></td> <td>The timestamp that was valid at the access event's creation.</td> </tr> @@ -3745,20 +3746,20 @@ public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> { href="#AccessSiftingAppender">SiftingAppender</a></h3> The SiftingAppender in logback-access is quite similar to its - logbacl-classic counterpart. The main difference is that in + logback-classic counterpart. The main difference is that in logback-access the default discriminator, namely <a href="../xref/ch/qos/logback/access/sift/AccessEventDiscriminator.html">AccessEventDiscriminator</a>, is not MDC based. As its name suggests, AccessEventDiscriminator, uses a designated field in AccessEvent as basis for selecting a nested appender. If the value of the designated field is null, then the value specified in the DefaultValue property is used. + class="option">DefaultValue property is used. The desginated AccessEvent field can be one of COOKIE, REQUEST_ATTRIBUTE, SESSION_ATTRIBUTE, REMOTE_ADDRESS, LOCAL_PORT, REQUEST_URI. Note that the first three fields require that the - AdditionalKey property also to be + AdditionalKey property also be specified. Below is an example configuration file. @@ -3790,7 +3791,7 @@ public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> { nests <code>FileAppender</code> instances. The key "id" is designated as a variable which will be availabe to the nested <code>FileAppender</code> instances. The default discriminator, - namely <code>AccessEventDiscriminator</code>, will search for + namely <code>AccessEventDiscriminator</code>, will search for a "username" session attribute in each <code>AccessEvent</code>. If no such attribute is available, then the default value "NA" will be used. Thus, assuming the session attribute named "username" diff --git a/logback-site/src/site/pages/manual/configuration.html b/logback-site/src/site/pages/manual/configuration.html index 3971387..d1fa5dc 100644 --- a/logback-site/src/site/pages/manual/configuration.html +++ b/logback-site/src/site/pages/manual/configuration.html @@ -189,7 +189,7 @@ public class Foo { to the root logger. The output is formatted using a <code>PatternLayout</code> set to the pattern %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n. Moreover, by default - the root logger is assigned to the <code>DEBUG</code> level. + the root logger is assigned the <code>DEBUG</code> level. Thus, the output of the command java chapter3.MyApp1 @@ -290,7 +290,7 @@ public class Foo { If everything goes well, you should see the following output on the console - <div class="source"><pre>17:44:58,578 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback-test.xml] + <div class="source longline"><pre>17:44:58,578 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback-test.xml] 17:44:58,671 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set 17:44:58,671 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender] 17:44:58,687 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [STDOUT] diff --git a/logback-site/src/site/pages/manual/introduction.html b/logback-site/src/site/pages/manual/introduction.html index 90259f0..32d993f 100644 --- a/logback-site/src/site/pages/manual/introduction.html +++ b/logback-site/src/site/pages/manual/introduction.html @@ -168,7 +168,7 @@ public class HelloWorld2 { Running the <code>HelloWorld2</code> application will produce the following output: -<div class="source"><pre>12:49:22.203 [main] DEBUG chapter1.HelloWorld2 - Hello world. +<div class="source longline"><pre>12:49:22.203 [main] DEBUG chapter1.HelloWorld2 - Hello world. 12:49:22,078 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml] 12:49:22,093 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.xml] 12:49:22,093 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Setting up default configuration. ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/css/common.css | 5 +- logback-site/src/site/pages/manual/appenders.html | 219 ++++++++++---------- .../src/site/pages/manual/configuration.html | 4 +- .../src/site/pages/manual/introduction.html | 2 +- 4 files changed, 117 insertions(+), 113 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

ApacheCon
by ralph.goers ＠dslextreme.com 29 Oct '09

29 Oct '09

If by any chance you will be attending ApacheCon next week in Oakland please let me know. I will be there Monday through Friday. Ralph

3 2

branch, master, updated. a2eb7c52b0312856e6f4c67670a4a11df4272780
by git-noreply＠pixie.qos.ch 28 Oct '09

28 Oct '09

The branch, master has been updated via a2eb7c52b0312856e6f4c67670a4a11df4272780 (commit) from 392672023cda2281b905c62f730cdd3b585aa853 (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=a2eb7c52b0312856e6f4c676… http://github.com/ceki/logback/commit/a2eb7c52b0312856e6f4c67670a4a11df4272… commit a2eb7c52b0312856e6f4c67670a4a11df4272780 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Wed Oct 28 22:54:50 2009 +0100 - Applied http://github.com/cehjohnson/logback/commit/2194ab44141abed25479ec00e4a88b4… from October 04, 2009 However, the ">" to ">" transformation has been ignored and will continue to be so in the future. diff --git a/logback-site/src/site/pages/manual/configuration.html b/logback-site/src/site/pages/manual/configuration.html index f725cf7..3971387 100644 --- a/logback-site/src/site/pages/manual/configuration.html +++ b/logback-site/src/site/pages/manual/configuration.html @@ -64,14 +64,14 @@ Inserting log requests into the application code requires a fair amount of planning and effort. Observation shows that approximately four percent of code is dedicated to - logging. Consequently, even moderately sized applications will + logging. Consequently, even a moderately sized application will contain thousands of logging statements embedded within its code. Given their number, we need tools to manage these log statements. - Logback can be configured either programmatically or with - configuration a script (expressed in XML format). By the way, + Logback can be configured either programmatically or with a + configuration script (expressed in XML format). By the way, existing log4j users can convert their log4j.properties files to logback.xml using our <a href="http://logback.qos.ch/translator/">PropertiesTranslator</a> @@ -124,7 +124,7 @@ <h3>Automatically configuring logback</h3> The simplest way to configure logback is by letting logback - fallback to its default configuration. Let us give a taste of how + fall back to its default configuration. Let us give a taste of how this is done in an imaginary application called <code>MyApp1</code>. @@ -213,8 +213,8 @@ public class Foo { The <code>MyApp1</code> application links to logback via calls <code>org.slf4j.LoggerFactory</code> and <code>org.slf4j.Logger</code> classes, retrieve the loggers it - wishes to use, and chugs on. Note that the only dependence of the - <code>Foo</code> class on logback are through + wishes to use, and chugs on. Note that the only dependencies of + the <code>Foo</code> class on logback are through <code>org.slf4j.LoggerFactory</code> and <code>org.slf4j.Logger</code> imports. Except code that configures logback (if such code exists) client code does not need to depend @@ -350,14 +350,14 @@ public class Foo { <li>the configuration file is well-formed XML.</li> </ol> - If any of these two conditions is not fulfilled, the Joran - cannot interpret <code>debug</code> attribute since the - configuration file cannot be read. If the configuration file is - found but is ill-formed, then logback will detect the error - condition and automatically print its internal status on the - console. However, if the configuration file cannot be found, since - this is not necessarily an error condition, logback will not - automatically print its status data. Programmatically invoking + If any of these two conditions is not fulfilled, Joran cannot + interpret <code>debug</code> attribute since the configuration file + cannot be read. If the configuration file is found but is + ill-formed, then logback will detect the error condition and + automatically print its internal status on the console. However, if + the configuration file cannot be found, since this is not + necessarily an error condition, logback will not automatically + print its status data. Programmatically invoking <code>StatusPrinter.print()</code>, as as in MyApp2 application above, ensures that status information is always printed. @@ -462,7 +462,7 @@ public class Foo { override logback's default configuration mechanism, you can do so by invoking <code>JoranConfigurator</code> directly. The next application, MyApp3, invokes JoranConfigurator on a - configuration file passed as parameter. + configuration file passed as a parameter. Example 3.: Invoking <code>JoranConfigurator</code> directly <a @@ -528,7 +528,7 @@ public class MyApp3 { Given a <code>StatusManager</code> you an access all the status data associated with a logback context. To keep memory usage at reasonable levels, the default <code>StatusManager</code> - implementation stores the status messages in two separate parts, + implementation stores the status messages in two separate parts: the header part and the tail part. The header part stores the fist H status messages whereas the tail part stores the last T messages. At present time H=T=150, @@ -585,7 +585,7 @@ public class MyApp3 { Here is <a href="../xref/chapter3/AddStatusListenerApp.html">sample code</a> - to register a OnConsoleStatusListener instance with the + to register an OnConsoleStatusListener instance with the StatusManager. @@ -637,12 +637,12 @@ public class MyApp3 { As shall become clear, the syntax of logback configuration files - is extremely flexible. As such, it is not possible specify the - allowed syntax with a DTD file or an XML Schema. Nevertheless, the - very basic structure of configuration can be described as, + is extremely flexible. As such, it is not possible to specify the + allowed syntax with a DTD file or an XML schema. Nevertheless, the + very basic structure of the configuration file can be described as, <configuration> element, followed by zero or more <appender> - elements, followed by by zero or more <logger> elements, followed - by at most one <root> element. The following diagram illustrates + elements, followed by zero or more <logger> elements, followed by + at most one <root> element. The following diagram illustrates this basic structure. diff --git a/logback-site/src/site/pages/manual/introduction.html b/logback-site/src/site/pages/manual/introduction.html index f8b0581..90259f0 100644 --- a/logback-site/src/site/pages/manual/introduction.html +++ b/logback-site/src/site/pages/manual/introduction.html @@ -193,7 +193,7 @@ public class HelloWorld2 { larger application would not be that different. The general pattern for logging statements would not change. Only the configuration process would be different. However, you would probably want to - customize or configure logback according to your needs. Logback + customize or configure logback according to your needs. Logback configuration will be covered in subsequent chapters. ----------------------------------------------------------------------- Summary of changes: .../src/site/pages/manual/configuration.html | 44 ++++++++++---------- .../src/site/pages/manual/introduction.html | 2 +- 2 files changed, 23 insertions(+), 23 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

branch, master, updated. 392672023cda2281b905c62f730cdd3b585aa853
by git-noreply＠pixie.qos.ch 28 Oct '09

28 Oct '09

The branch, master has been updated via 392672023cda2281b905c62f730cdd3b585aa853 (commit) from 33dfb1600acd3d5e2c6f98e4f471be8ac3d796e2 (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=392672023cda2281b905c62f… http://github.com/ceki/logback/commit/392672023cda2281b905c62f730cdd3b585aa… commit 392672023cda2281b905c62f730cdd3b585aa853 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Wed Oct 28 22:27:35 2009 +0100 - applied cehjohnson's commit f257e840947c41c6ae5c5ed182e7ccb5c3ffd640 from October 02, 2009 diff --git a/logback-site/src/site/pages/manual/architecture.html b/logback-site/src/site/pages/manual/architecture.html index b1e7c31..6d353c3 100644 --- a/logback-site/src/site/pages/manual/architecture.html +++ b/logback-site/src/site/pages/manual/architecture.html @@ -44,7 +44,7 @@ <h2>Logback's architecture</h2> Logback's basic architecture is sufficiently generic so as to - apply under different circumstances. At present time, logback is + apply under different circumstances. At the present time, logback is divided into three modules, Core, Classic and Access. @@ -150,7 +150,7 @@ public interface Logger { that is TRACE, DEBUG, INFO, WARN and ERROR are defined in the <code>ch.qos.logback.classic.Level</code> class. Note that in logback, the level class is final and cannot be derived, as a much - more flexible approach exist in the form of <code>Marker</code> + more flexible approach exists in the form of <code>Marker</code> objects. @@ -244,7 +244,7 @@ public interface Logger { </table> In example 2 above, all loggers have an assigned level value. - Level inheritence does not come into play. + Level inheritance does not come into play. Example 3 @@ -358,7 +358,7 @@ public interface Logger { In a more graphic way, here is how the selection rule works. In - the following table, the vertical header shows the the level of + the following table, the vertical header shows the level of the logging request, designated by p, while the horizontal header shows effective level of the logger, designated by q. The intersection of the rows (level request) and @@ -541,8 +541,8 @@ Logger y = LoggerFactory.getLogger("wombat");</pre> However, if an ancestor of logger L, say P, has the additivity flag set to false, then L's output - will be directed to all the appenders in L and it's - ancestors upto and including P but not the appenders in + will be directed to all the appenders in L and its + ancestors up to and including P but not the appenders in any of the ancestors of P. @@ -727,7 +727,7 @@ logger.debug("Value {} was inserted between {} and {}.", paramArray);</pre> <a name="UnderTheHood"></a> - <h3>A peak under the hood</h3> + <h3>A peek under the hood</h3> After we have introduced the essential logback components, we are now ready to describe the steps that the logback framework takes @@ -762,7 +762,7 @@ logger.debug("Value {} was inserted between {} and {}.", paramArray);</pre> <h4>3. Create a <code>LoggingEvent</code> object</h4> - If the request survivedy the previous filters, logback will + If the request survived the previous filters, logback will create a <code>ch.qos.logback.classic.LoggingEvent</code> object containing all the relevant parameters of the request, such as the logger of the request, the request level, the message itself, the @@ -854,7 +854,7 @@ logger.debug("Value {} was inserted between {} and {}.", paramArray);</pre> The cost of parameter construction can be quite high and depends on the size of the parameters involved. To avoid the cost of - parameter construction you can take advantage of SLF4J's parametrized + parameter construction you can take advantage of SLF4J's parameterized logging: @@ -872,9 +872,9 @@ logger.debug("Value {} was inserted between {} and {}.", paramArray);</pre> Please notice that, despite the performance points that we just - discussed, inserting logging statements in tight-loops or very + discussed, inserting logging statements in tight loops or very frequently invoked code is a lose-lose proposal and is likely to - result in degraded performance. Logging in tight-loops slow down + result in degraded performance. Logging in tight loops slow down your application even if logging is turned off, and if logging is turned on, they will generate massive (and hence useless) output. diff --git a/logback-site/src/site/pages/manual/introduction.html b/logback-site/src/site/pages/manual/introduction.html index 3d7a2d0..f8b0581 100644 --- a/logback-site/src/site/pages/manual/introduction.html +++ b/logback-site/src/site/pages/manual/introduction.html @@ -123,12 +123,12 @@ public class HelloWorld1 { You can launch the first - sample application, chapter1.HelloWord1 with the command: + sample application, chapter1.HelloWorld1 with the command: <div class="source"><pre>java chapter1.HelloWorld1</pre></div> Launching the <code>HelloWorld1</code> application will output - a single line on the console. By virtue of to logback's default + a single line on the console. By virtue of logback's default configuration policy, when no default configuration file is found, logback will add a <code>ConsoleAppender</code> to the root logger. @@ -191,9 +191,9 @@ public class HelloWorld2 { The previous examples are rather simple. Actual logging in a larger application would not be that different. The general pattern - for logging statements would not change. nly the configuration - process would be different since However, you would probably want to - customize or configure logback for according to your needs. Logback + for logging statements would not change. Only the configuration + process would be different. However, you would probably want to + customize or configure logback according to your needs. Logback configuration will be covered in subsequent chapters. @@ -216,7 +216,7 @@ public class HelloWorld2 { <code>Logger</code> instance by invoking the <code>org.slf4j.LoggerFactory</code> class' <code>getLogger()</code> method, passing the current class name - or the class itself as parameter.</li> + or the class itself as a parameter.</li> <li>Use this logger instance by invoking its printing methods, namely the debug(), info(), warn() and error(). This will ----------------------------------------------------------------------- Summary of changes: .../src/site/pages/manual/architecture.html | 22 ++++++++++---------- .../src/site/pages/manual/introduction.html | 12 +++++----- 2 files changed, 17 insertions(+), 17 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[JIRA] Created: (LBCLASSIC-163) LoggingEventVO does not serialize the argument array properly.
by Ralph Goers (JIRA) 26 Oct '09

26 Oct '09

LoggingEventVO does not serialize the argument array properly. -------------------------------------------------------------- Key: LBCLASSIC-163 URL: http://jira.qos.ch/browse/LBCLASSIC-163 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.917 Reporter: Ralph Goers Assignee: Logback dev list LoggingEventVO serializes the objects in the argument array by simply calling toString(). This makes it impossible to reconstruct the objects on the remote side. I have fixed this in my fork at git://github.com/rgoers/logback.git by serializing the object if it implements Serializable and converting it to a String if it does not. -- 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

4 14

[JIRA] Created: (LBCLASSIC-164) Make the aspect of encoding a LoggingEvent pluggable, and thus the Appender implementation more reusable.
by Maarten Bosteels (JIRA) 24 Oct '09

24 Oct '09

Make the aspect of encoding a LoggingEvent pluggable, and thus the Appender implementation more reusable. --------------------------------------------------------------------------------------------------------- Key: LBCLASSIC-164 URL: http://jira.qos.ch/browse/LBCLASSIC-164 Project: logback-classic Issue Type: New Feature Components: appender Reporter: Maarten Bosteels Assignee: Logback dev list Refactor the encoding out of appender implementations, by adding an Encoder interface to logback. prototype: http://code.google.com/p/firewood/source/browse/trunk/compare-formats/src/m… -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 1

LoggingEventVO and serialization
by Ralph Goers 22 Oct '09

22 Oct '09

I am going to be creating a logging service. The architecture in our POC is the client uses the JMSTopicAppender writing to ActiveMQ and then the service will listen on the topic and write to the destination. To avoid having the messages be logback specific so that our legacy system can also interact with this I will be serializing the messages according the the IETFSyslogLayout in my fork of Logback (i.e. all the messages will comply with RFC 5424). I got this working today with the output temporarily going to syslog-ng (which supports IETF syslog messages). Of Course, JMSTopicAppender and JMSQueueAppender had to be modified to allow a different form of serialization. This was easily done by just seeing if a layout was configured. If so, then LayoutPreSerializationTransformer is used instead of LoggingEventPreSerializationTransformer. However, just for fun I tried serializing to LoggingEventVO using the default mechanisms in place and sending that through the JMS Appender to the JMSTopicSink. It didn't quite work correctly. In looking at why I discovered the LoggingEventVO serializes arguments by calling toString(). So when the JMSAppender transforms the objects their object type is lost. This means on the remote side it is impossible to convert them back to the original object. I would think that some form of the Serialized object should be in the argument array instead of just a String. Otherwise it is impossible to get the remote side to behave like the original client. Ralph

1 0

[JIRA] Created: (LBGENERAL-33) SMTPAppender_SubethaSMTPTest hang
by Ralph Goers (JIRA) 21 Oct '09

21 Oct '09

SMTPAppender_SubethaSMTPTest hang --------------------------------- Key: LBGENERAL-33 URL: http://jira.qos.ch/browse/LBGENERAL-33 Project: logback-general Issue Type: Sub-task Affects Versions: 0.9.17 Environment: Mac OSX Reporter: Ralph Goers Assignee: Logback dev list This test frequently waits forever waiting for a response. The jstack output follows: 2009-10-13 09:59:33 Full thread dump Java HotSpot(TM) 64-Bit Server VM (14.1-b02-90 mixed mode): "Attach Listener" daemon prio=9 tid=0x00000001022f4800 nid=0x1150c6000 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "SocketAcceptorIoProcessor-2.0" prio=5 tid=0x000000011316f000 nid=0x115487000 runnable [0x0000000115486000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method) at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:136) at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:69) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x00000001064d86b8> (a sun.nio.ch.Util$1) - locked <0x00000001064d86a0> (a java.util.Collections$UnmodifiableSet) - locked <0x00000001064d8340> (a sun.nio.ch.KQueueSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80) at org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:480) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:637) "SocketAcceptor-2" prio=5 tid=0x0000000102196800 nid=0x114e4e000 runnable [0x0000000114e4d000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method) at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:136) at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:69) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x0000000107ad72c0> (a sun.nio.ch.Util$1) - locked <0x0000000107ad72d8> (a java.util.Collections$UnmodifiableSet) - locked <0x0000000107aee2b8> (a sun.nio.ch.KQueueSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:84) at org.apache.mina.transport.socket.nio.SocketAcceptor$Worker.run(SocketAcceptor.java:220) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:637) "HSQLDB Timer @e8ae59a" daemon prio=5 tid=0x0000000113421800 nid=0x114fc3000 in Object.wait() [0x0000000114fc2000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000001072e8c08> (a org.hsqldb.lib.HsqlTimer) at org.hsqldb.lib.HsqlTimer.nextTask(Unknown Source) - locked <0x00000001072e8c08> (a org.hsqldb.lib.HsqlTimer) at org.hsqldb.lib.HsqlTimer$TaskRunner.run(Unknown Source) at java.lang.Thread.run(Thread.java:637) "Thread-5" prio=5 tid=0x00000001023ac800 nid=0x114b1b000 runnable [0x0000000114b1a000] java.lang.Thread.State: RUNNABLE at java.net.PlainDatagramSocketImpl.receive0(Native Method) - locked <0x00000001071a3c58> (a java.net.PlainDatagramSocketImpl) at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136) - locked <0x00000001071a3c58> (a java.net.PlainDatagramSocketImpl) at java.net.DatagramSocket.receive(DatagramSocket.java:712) - locked <0x00000001071c6cd8> (a java.net.DatagramPacket) - locked <0x0000000107195e18> (a java.net.DatagramSocket) at ch.qos.logback.classic.net.mock.MockSyslogServer.run(MockSyslogServer.java:50) "Thread-4" prio=5 tid=0x000000011321f800 nid=0x114a18000 runnable [0x0000000114a17000] java.lang.Thread.State: RUNNABLE at java.net.PlainDatagramSocketImpl.receive0(Native Method) - locked <0x00000001071a3cb0> (a java.net.PlainDatagramSocketImpl) at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136) - locked <0x00000001071a3cb0> (a java.net.PlainDatagramSocketImpl) at java.net.DatagramSocket.receive(DatagramSocket.java:712) - locked <0x00000001071c6d08> (a java.net.DatagramPacket) - locked <0x0000000107195e50> (a java.net.DatagramSocket) at ch.qos.logback.classic.net.mock.MockSyslogServer.run(MockSyslogServer.java:50) "Thread-3" prio=5 tid=0x000000010241d800 nid=0x114915000 runnable [0x0000000114914000] java.lang.Thread.State: RUNNABLE at java.net.PlainDatagramSocketImpl.receive0(Native Method) - locked <0x0000000107104030> (a java.net.PlainDatagramSocketImpl) at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136) - locked <0x0000000107104030> (a java.net.PlainDatagramSocketImpl) at java.net.DatagramSocket.receive(DatagramSocket.java:712) - locked <0x0000000107125850> (a java.net.DatagramPacket) - locked <0x00000001071243f8> (a java.net.DatagramSocket) at ch.qos.logback.classic.net.mock.MockSyslogServer.run(MockSyslogServer.java:50) "Thread-1" prio=5 tid=0x000000011316c000 nid=0x114703000 runnable [0x0000000114702000] java.lang.Thread.State: RUNNABLE at java.net.PlainDatagramSocketImpl.receive0(Native Method) - locked <0x0000000107077898> (a java.net.PlainDatagramSocketImpl) at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136) - locked <0x0000000107077898> (a java.net.PlainDatagramSocketImpl) at java.net.DatagramSocket.receive(DatagramSocket.java:712) - locked <0x00000001070e9668> (a java.net.DatagramPacket) - locked <0x00000001070f1b20> (a java.net.DatagramSocket) at ch.qos.logback.classic.net.mock.MockSyslogServer.run(MockSyslogServer.java:50) "Thread-0" prio=5 tid=0x0000000113113000 nid=0x1145ed000 runnable [0x00000001145ec000] java.lang.Thread.State: RUNNABLE at java.net.PlainDatagramSocketImpl.receive0(Native Method) - locked <0x00000001070778f0> (a java.net.PlainDatagramSocketImpl) at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136) - locked <0x00000001070778f0> (a java.net.PlainDatagramSocketImpl) at java.net.DatagramSocket.receive(DatagramSocket.java:712) - locked <0x00000001070e9698> (a java.net.DatagramPacket) - locked <0x00000001070f1b58> (a java.net.DatagramSocket) at ch.qos.logback.classic.net.mock.MockSyslogServer.run(MockSyslogServer.java:50) "Low Memory Detector" daemon prio=5 tid=0x000000010208e000 nid=0x114290000 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "CompilerThread1" daemon prio=9 tid=0x000000010208d800 nid=0x11418d000 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "CompilerThread0" daemon prio=9 tid=0x000000010208c800 nid=0x11408a000 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" daemon prio=9 tid=0x000000010208c000 nid=0x113f87000 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Surrogate Locker Thread (CMS)" daemon prio=5 tid=0x000000010208b000 nid=0x113e84000 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Finalizer" daemon prio=8 tid=0x0000000102075800 nid=0x113b07000 in Object.wait() [0x0000000113b06000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x0000000106ef0848> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118) - locked <0x0000000106ef0848> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=10 tid=0x0000000113026000 nid=0x113a04000 in Object.wait() [0x0000000113a03000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x0000000106ef0860> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:485) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x0000000106ef0860> (a java.lang.ref.Reference$Lock) "main" prio=5 tid=0x0000000102000800 nid=0x101301000 runnable [0x00000001012fe000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at com.sun.mail.util.TraceInputStream.read(TraceInputStream.java:97) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:237) - locked <0x0000000106458610> (a java.io.BufferedInputStream) at com.sun.mail.util.LineInputStream.readLine(LineInputStream.java:75) at com.sun.mail.smtp.SMTPTransport.readServerResponse(SMTPTransport.java:1440) at com.sun.mail.smtp.SMTPTransport.issueSendCommand(SMTPTransport.java:1376) at com.sun.mail.smtp.SMTPTransport.finishData(SMTPTransport.java:1215) at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:586) - locked <0x0000000106454d10> (a com.sun.mail.smtp.SMTPTransport) at javax.mail.Transport.send0(Transport.java:169) at javax.mail.Transport.send(Transport.java:98) at ch.qos.logback.core.net.SMTPAppenderBase.sendBuffer(SMTPAppenderBase.java:282) at ch.qos.logback.core.net.SMTPAppenderBase.append(SMTPAppenderBase.java:153) at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:91) - locked <0x000000010710e350> (a ch.qos.logback.classic.net.SMTPAppender) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:64) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:276) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:263) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:445) at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:399) at ch.qos.logback.classic.Logger.error(Logger.java:562) at ch.qos.logback.classic.net.SMTPAppender_SubethaSMTPTest.htmlLong(SMTPAppender_SubethaSMTPTest.java:195) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) "VM Thread" prio=9 tid=0x0000000102070000 nid=0x113901000 runnable "Gang worker#0 (Parallel GC Threads)" prio=9 tid=0x0000000102002000 nid=0x105902000 runnable "Gang worker#1 (Parallel GC Threads)" prio=9 tid=0x0000000102002800 nid=0x105a05000 runnable "Concurrent Mark-Sweep GC Thread" prio=9 tid=0x0000000102042000 nid=0x112d9f000 runnable "VM Periodic Task Thread" prio=10 tid=0x000000010208f000 nid=0x114393000 waiting on condition "Exception Catcher Thread" prio=10 tid=0x0000000102001800 nid=0x101701000 runnable JNI global references: 939 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 1

branch, master, updated. 33dfb1600acd3d5e2c6f98e4f471be8ac3d796e2
by git-noreply＠pixie.qos.ch 16 Oct '09

16 Oct '09

The branch, master has been updated via 33dfb1600acd3d5e2c6f98e4f471be8ac3d796e2 (commit) from 7746ef887110ae043226be2b6cc78c7c28b66df8 (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=33dfb1600acd3d5e2c6f98e4… http://github.com/ceki/logback/commit/33dfb1600acd3d5e2c6f98e4f471be8ac3d79… commit 33dfb1600acd3d5e2c6f98e4f471be8ac3d796e2 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Fri Oct 16 21:01:43 2009 +0200 logback-announce replaced by announce(a)qos.ch diff --git a/logback-site/src/site/pages/news.html b/logback-site/src/site/pages/news.html index 98c64be..a0e1217 100644 --- a/logback-site/src/site/pages/news.html +++ b/logback-site/src/site/pages/news.html @@ -23,8 +23,7 @@ <h2>Logback News</h2> You can receive logback-related announcements by subscribing to - the <a - href="http://www.qos.ch/mailman/listinfo/logback-announce">logback + the <a href="http://www.qos.ch/mailman/listinfo/announce">QOS.ch announce</a> mailing list. <hr width="80%" align="center" /> ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/news.html | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0