- logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCORE-125) Typo in methodname of ch.qos.logback.core.ContextBase
by Joern Huxhorn (JIRA) 05 Nov '09

05 Nov '09

Typo in methodname of ch.qos.logback.core.ContextBase ----------------------------------------------------- Key: LBCORE-125 URL: http://jira.qos.ch/browse/LBCORE-125 Project: logback-core Issue Type: Improvement Affects Versions: 0.9.17 Reporter: Joern Huxhorn Assignee: Logback dev list getBithTime should be getBirthTime -- 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

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

05 Nov '09

The branch, master has been updated via 0acd6c2cbb7b85bbd909411e6ad470a5e0d3c64b (commit) from 46070d291951284bb5ab647090b44f4aff4593b0 (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=0acd6c2cbb7b85bbd909411e… http://github.com/ceki/logback/commit/0acd6c2cbb7b85bbd909411e6ad470a5e0d3c… commit 0acd6c2cbb7b85bbd909411e6ad470a5e0d3c64b Author: Ceki Gulcu <ceki(a)qos.ch> Date: Thu Nov 5 11:02:35 2009 +0100 - changed url of logback config wizard diff --git a/logback-site/src/site/pages/download.html b/logback-site/src/site/pages/download.html index 5326635..8004509 100644 --- a/logback-site/src/site/pages/download.html +++ b/logback-site/src/site/pages/download.html @@ -61,7 +61,7 @@ <dl> <dt> <a - href="http://wizardforge.org/pc?action=showVersion&id=72">Configuration + href="http://wizardforge.org/pc?action=displayFlowchartVersionPublic&id=42">Configuration wizard</a> by Dirk Ooms </dt> ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/download.html | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

JMX Triggered Rollover for RollingFileAppender
by Tom Liu 04 Nov '09

04 Nov '09

Hi logback dev, We use RollingFileAppender quite heavily and it works perfect for us in most cases. However, in some situation, we find the local file system we're logging to is almost full when our application is still running, so we want to trigger a rollover manually via jmx, which archives the log file to a networked file system. In this way, we can make some extra space on local file system and prevent losing logs. Would you like to consider adding jmx triggered rollover feature, which could work with all the built-in rolling policies (FixedWindowRollingPolicy and TimeBasedRollingPolicy) ? Is there any way to achieve jmx triggered rollover in logback at this moment? I've filed a jira here: http://jira.qos.ch/browse/LBCORE-124 Thanks in advance ! Best Regards, Tom

1 0

[JIRA] Created: (LBCORE-124) JMX Triggered Rollover for RollingFileAppender
by tomliliu (JIRA) 04 Nov '09

04 Nov '09

JMX Triggered Rollover for RollingFileAppender ---------------------------------------------- Key: LBCORE-124 URL: http://jira.qos.ch/browse/LBCORE-124 Project: logback-core Issue Type: New Feature Components: Rolling Affects Versions: 0.9.17 Reporter: tomliliu Assignee: Logback dev list Priority: Minor Hi logback dev, We use RollingFileAppender quite heavily and it works perfect for us in most cases. However, in some situation, we find the local file system we're logging to is almost full when our application is still running, so we want to trigger a rollover manually via jmx, which archives the log file to a networked file system. In this way, we can make some extra space on local file system and prevent losing logs. Would you like to consider adding jmx triggered rollover feature, which could work with all the built-in rolling policies (FixedWindowRollingPolicy and TimeBasedRollingPolicy) ? Is there any way to achieve jmx triggered rollover in logback at this moment? Thanks in advance! Best Regards, Tom -- 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: (LBGENERAL-36) Logging of java.lang.reflect.Type[] only displays the first element
by Jeff Jensen (JIRA) 03 Nov '09

03 Nov '09

Logging of java.lang.reflect.Type[] only displays the first element ------------------------------------------------------------------- Key: LBGENERAL-36 URL: http://jira.qos.ch/browse/LBGENERAL-36 Project: logback-general Issue Type: Bug Affects Versions: 0.9.17 Environment: Windows 7 Reporter: Jeff Jensen Assignee: Logback dev list Logging of arrays typically works fine. I encountered a situation where Logback only displays the first element of the array. I created a test case to demonstrate. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 4

Logback extensibility design.
by Gabriele Contini 02 Nov '09

02 Nov '09

Hi, I was facing a problem with Logback (the one described here http://jira.qos.ch/browse/LBCLASSIC-166) and i tried to extend the design of logback to implement this new feature without modifing the existing code. I found only one pre-defined extension point: the ContextSelector mechanism. But however i turn around the problem i can't extend Logback functionality without modifying the library. I think a "base library" should be extensible to fit different user needs and not "blocked" to extensions. The problems i've found are the following: * In my opinion LoggerContext should be (where possible) changed into ILoggerFactory in ContextSelector interface. Thus allowing for user defined LoggerContext implementation to be plugged in. * Moreover LoggerContext.getLogger(String) shouldn't be final, allowing users to subclass the LoggerContext and provide their own loggers implementation. It should also return an instance of org.slf4j.Logger as defined in ILoggerFactory interface (and not an ch.qos.logback.classic.Logger that's final and unchangeable). * At this stage of my work i cant' understand if i'll need to subclass ch.qos.logback.classic.Logger or i can just implement a org.slf4j.Logger that forwards his calls to a ch.qos.logback.classic.Logger instance. Anyway I'm sure that my work would be easier if ch.qos.logback.classic.Logger is not final. Best regards. Gabriele Contini

1 0

[JIRA] Commented: (LBCLASSIC-87) LoggerContextFilter is useless (org.slf4j.Loggerfactory bug ++)
by Gabriele Contini (JIRA) 02 Nov '09

02 Nov '09

[ http://jira.qos.ch/browse/LBCLASSIC-87?page=com.atlassian.jira.plugin.syste… ] Gabriele Contini commented on LBCLASSIC-87: ------------------------------------------- Hello Ceki, In my opinion static logger references in shared libraries should be able to switch context (maybe based on MDC or Environment values). I opened a new jira issue as you suggested. Please refer to: LBCLASSIC-166. Best regards. Gabriele Contini > LoggerContextFilter is useless (org.slf4j.Loggerfactory bug ++) > --------------------------------------------------------------- > > Key: LBCLASSIC-87 > URL: http://jira.qos.ch/browse/LBCLASSIC-87 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Jens Elkner > Assignee: Logback dev list > > Since LoggerFactory obtains the LoggerContext to use in its static init stage, using a LoggerContextFilter as described in Chapter 8 is completely useless, since the JNDI selector is never consulted again. > Digging deeper on that issue reveals, that using a ContextJNDISelector (even if it would work) rarely leads to the intended behavior (e.g. webapp related logging), and is probably not thread safe wrt. common practice and intended logging. E.g. in tomcat we have two different cases: > a) each webapp provides its own slfj4*.jar as well as *logback*.jar > b) slfj4*.jar as well as *logback*.jar are shared via tomcat/common/lib or > tomcat/share/lib > c) a und b mixed > Well, to get things right, one can say case c) is unsupported ;-). > In case a) logback has its own playground, so using JNDI doesn't make sense at all, since the webapp/logback has its own playground - doesn't interfere with > other web apps since loaded via its dedicated classloader. > However case b) is a little bit more challenging. Here the LoggerFactory and other classes are !shared! between several webapps, since loading is delegated from the dedicated webapp classloader to the shared webapp classloader, which picks up everything in share/lib , common/lib. So right now in 0.9.7, even if one uses JNDISelector a per webapp logging is impossible: The first webapp, which asks for a LoggerFactory always wins! All other webapps, which ask later for a LoggerFactory.getLogger() will get a Logger from the LoggerContext associated with the first webapp, since the context is "cached", i.e. the JNDI selector gets never consulted again. > Assuming the LoggerFactory problem gets fixed by using e.g. > public static Logger getLogger(* *) { > return StaticLoggerBinder.SINGLETON.getLoggerFactory().getLogger(**); > } > there is still a problem wrt. common practice aka log* usage pattern and webapp shared classes, which can not be resolved by JNDI: Today most developer use something like: > public class XY { > private static [final] Logger log = LoggerFactory.getLogger(XY.class); > ... > } > That implies the same problem, as with the current LoggerFactory bug: The class gets the Logger from the context associated with the first webapp, which needs the shared class. And that's why all other webapps, which later need this class will use the the logger context of the first webapp. So e.g. if webapp A is configured to log to /var/log/a.log and another webapp B is configured to log to /var/log/b.log the loging output of shared classes will always go to /var/log/a.log if webapp used the classes in question first, no matter on which thread aka in which webapp the shared classes are used. > So even if LoggerFactory gets fixed, JNDI selector is of little use, if one wants to have a webapp dedicated log as soon as shared classes are involved. > The only way to solve the didcated webapp log problem a can think of, to introduce another level of indirection in the Logger.log* etc. method, which takes care of thread local settings and the settings of its parent threads (e.g. an application may start other threads, which do not inherit the thread local settings from the current thread ...). But this would probably influence the performance of logback in a rather negative way. > Another idea might be an architecture re-design: sharing Loggers would be no problem because of thread local AppenderContext soft ref, which points to an Appender in the global AppenderStore singleton ... > RFE: These problems should be reflected chapter 8 of the logback manual to avoid further confusion ... -- 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

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