August 2007 - logback-dev - mailman3.qos.ch

[Bug 84] New: LoggerContextFilter is useless (org.slf4j.Loggerfactory bug ++)
by bugzilla-daemon＠pixie.qos.ch 18 Sep '07

18 Sep '07

http://bugzilla.qos.ch/show_bug.cgi?id=84 Summary: LoggerContextFilter is useless (org.slf4j.Loggerfactory bug ++) Product: logback-core Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: Other AssignedTo: logback-dev(a)qos.ch ReportedBy: jel(a)linofee.org 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 ... -- Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 3

MDC good concept but...Thread-Support
by peter huber 30 Aug '07

30 Aug '07

Hi LogBack-Team, just want to tell you that MDC lacks thread support. But I'm quite sure that you know that. As soon as you "leave" a thread the MDC conext (ThreadLocal) will be lost. I had implemented something similar to MDC a while ago and I accompanied my impl with a ContextPreservingRunnable after a while. Works like this CTOR (Source Thread): ContextPreservingRunnable(Runnable inSubject) { myMemento = MDC.getMemento(); mySubject = inSubject; } RUN-Method (Target Thread): void run() { MDC.setMemento(myMemento); mySubject.run(); MDC.clear(); } Even though it works for me, it's rather bad that you have to wrap all Runnables and Callables respectively. Maybe a ExecutorFacade might server the purpose? BTW: Does MDC include support for a Subjects Principals (JAAS)...Please forgive me my showing off at dev list;-) __________________________________ Yahoo! Clever - Der einfachste Weg, Fragen zu stellen und Wissenswertes mit Anderen zu teilen. www.yahoo.de/clever

3 2

svn commit: r1583 - in logback/trunk: logback-classic/src/main/java/org/slf4j/impl logback-examples/src/main/java/chapter7 logback-site/src/site/pages logback-site/src/site/pages/manual
by noreply.ceki＠qos.ch 29 Aug '07

29 Aug '07

Author: ceki Date: Wed Aug 29 23:59:52 2007 New Revision: 1583 Modified: logback/trunk/logback-classic/src/main/java/org/slf4j/impl/LogbackMDCAdapter.java logback/trunk/logback-examples/src/main/java/chapter7/SimpleMDC.java logback/trunk/logback-examples/src/main/java/chapter7/UserServletFilter.java logback/trunk/logback-site/src/site/pages/manual/mdc.html logback/trunk/logback-site/src/site/pages/news.html Log: - MDC data in now inheritable by child threads. This fixes bug #64. - updated MDC docs Modified: logback/trunk/logback-classic/src/main/java/org/slf4j/impl/LogbackMDCAdapter.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/org/slf4j/impl/LogbackMDCAdapter.java (original) +++ logback/trunk/logback-classic/src/main/java/org/slf4j/impl/LogbackMDCAdapter.java Wed Aug 29 23:59:52 2007 @@ -7,9 +7,9 @@ import org.slf4j.spi.MDCAdapter; /** - * A <em>Mapped Diagnostic Context</em>, or MDC in short, is an instrument for - * distinguishing interleaved log output from different sources. Log output is - * typically interleaved when a server handles multiple clients + * A <em>Mapped Diagnostic Context</em>, or MDC in short, is an instrument + * for distinguishing interleaved log output from different sources. Log output + * is typically interleaved when a server handles multiple clients * near-simultaneously. * <p> * <b><em>The MDC is managed on a per thread basis</em></b>. A child thread @@ -22,17 +22,17 @@ * * @author Ceki Gülcü */ -public class LogbackMDCAdapter implements MDCAdapter { - - private final ThreadLocal<HashMap<String, String>> threadLocal = new ThreadLocal<HashMap<String, String>>(); +public class LogbackMDCAdapter implements MDCAdapter { + + private final InheritableThreadLocal<HashMap<String, String>> inheritableThreadLocal = new InheritableThreadLocal<HashMap<String, String>>(); LogbackMDCAdapter() { } /** * Put a context value (the <code>val</code> parameter) as identified with - * the <code>key</code> parameter into the current thread's context map. Note - * that contrary to log4j, the <code>val</code> parameter can be null. + * the <code>key</code> parameter into the current thread's context map. + * Note that contrary to log4j, the <code>val</code> parameter can be null. * * <p> * If the current thread does not have a context map it is created as a side @@ -40,25 +40,26 @@ * * <p> * Each time a value is added, a new instance of the map is created. This is - * to be certain that the serialization process will operate on the updated map - * and not send a reference to the old map, thus not allowing the remote logback - * component to see the latest changes. + * to be certain that the serialization process will operate on the updated + * map and not send a reference to the old map, thus not allowing the remote + * logback component to see the latest changes. * - * @throws IllegalArgumentException in case the "key" parameter is null + * @throws IllegalArgumentException + * in case the "key" parameter is null */ public void put(String key, String val) throws IllegalArgumentException { if (key == null) { throw new IllegalArgumentException("key cannot be null"); } - - HashMap<String, String> oldMap = threadLocal.get(); + + HashMap<String, String> oldMap = inheritableThreadLocal.get(); HashMap<String, String> newMap = new HashMap<String, String>(); if (oldMap != null) { - newMap.putAll(oldMap); + newMap.putAll(oldMap); } // the newMap replaces the old one for serialisation's sake - threadLocal.set(newMap); + inheritableThreadLocal.set(newMap); newMap.put(key, val); } @@ -69,7 +70,7 @@ * This method has no side effects. */ public String get(String key) { - HashMap<String, String> hashMap = threadLocal.get(); + HashMap<String, String> hashMap = inheritableThreadLocal.get(); if ((hashMap != null) && (key != null)) { return hashMap.get(key); @@ -83,19 +84,19 @@ * * <p> * Each time a value is removed, a new instance of the map is created. This is - * to be certain that the serialization process will operate on the updated map - * and not send a reference to the old map, thus not allowing the remote logback - * component to see the latest changes. + * to be certain that the serialization process will operate on the updated + * map and not send a reference to the old map, thus not allowing the remote + * logback component to see the latest changes. */ public void remove(String key) { - HashMap<String, String> oldMap = threadLocal.get(); + HashMap<String, String> oldMap = inheritableThreadLocal.get(); HashMap<String, String> newMap = new HashMap<String, String>(); if (oldMap != null) { - newMap.putAll(oldMap); + newMap.putAll(oldMap); } // the newMap replaces the old one for serialisation's sake - threadLocal.set(newMap); + inheritableThreadLocal.set(newMap); newMap.remove(key); } @@ -103,11 +104,11 @@ * Clear all entries in the MDC. */ public void clear() { - HashMap<String, String> hashMap = threadLocal.get(); + HashMap<String, String> hashMap = inheritableThreadLocal.get(); if (hashMap != null) { hashMap.clear(); - threadLocal.remove(); + inheritableThreadLocal.remove(); } } @@ -116,15 +117,15 @@ * internally. */ public Map<String, String> getPropertyMap() { - return threadLocal.get(); + return inheritableThreadLocal.get(); } /** - * Returns the keys in the MDC as a {@link Set}. The returned value - * can be null. + * Returns the keys in the MDC as a {@link Set}. The returned value can be + * null. */ public Set<String> getKeys() { - HashMap<String, String> hashMap = threadLocal.get(); + HashMap<String, String> hashMap = inheritableThreadLocal.get(); if (hashMap != null) { return hashMap.keySet(); Modified: logback/trunk/logback-examples/src/main/java/chapter7/SimpleMDC.java ============================================================================== --- logback/trunk/logback-examples/src/main/java/chapter7/SimpleMDC.java (original) +++ logback/trunk/logback-examples/src/main/java/chapter7/SimpleMDC.java Wed Aug 29 23:59:52 2007 @@ -10,10 +10,10 @@ package chapter7; +import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.slf4j.MDC; -import ch.qos.logback.classic.Logger; import ch.qos.logback.classic.PatternLayout; import ch.qos.logback.classic.spi.LoggingEvent; import ch.qos.logback.core.ConsoleAppender; @@ -31,11 +31,14 @@ ConsoleAppender<LoggingEvent> appender = new ConsoleAppender<LoggingEvent>(); appender.setLayout(layout); appender.start(); - Logger root = (Logger)LoggerFactory.getLogger("root"); + // cast root logger to c.q.logback.classic.Logger so that we can attach an + // appender to it + ch.qos.logback.classic.Logger root = (ch.qos.logback.classic.Logger) LoggerFactory + .getLogger("root"); root.addAppender(appender); - - // get a logger - Logger logger = (Logger)LoggerFactory.getLogger(SimpleMDC.class); + + // get another logger + Logger logger = LoggerFactory.getLogger(SimpleMDC.class); // We now put the last name MDC.put("last", "Parker"); Modified: logback/trunk/logback-examples/src/main/java/chapter7/UserServletFilter.java ============================================================================== --- logback/trunk/logback-examples/src/main/java/chapter7/UserServletFilter.java (original) +++ logback/trunk/logback-examples/src/main/java/chapter7/UserServletFilter.java Wed Aug 29 23:59:52 2007 @@ -61,7 +61,8 @@ HttpServletRequest req = (HttpServletRequest) request; Principal principal = req.getUserPrincipal(); - + // we could have also used a cookie to retreive the user name + if (principal != null) { String username = principal.getName(); registerUsername(username); Modified: logback/trunk/logback-site/src/site/pages/manual/mdc.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/manual/mdc.html (original) +++ logback/trunk/logback-site/src/site/pages/manual/mdc.html Wed Aug 29 23:59:52 2007 @@ -82,10 +82,12 @@ lets the developer place information in a <em>diagnostic context</em> that can be subsequently retrieved by certain logback components. The <code>MDC</code> manages contextual - information on a <em>per thread basis</em>. Typically, while - starting to service a new client request, the developer will - insert pertinent contextual information, such as the client id, - client's IP address, request parameters etc. into the + information on a <em>per thread basis</em>. A child thread * + automatically inherits a <em>copy</em> of the mapped diagnostic + context of * its parent. Typically, while starting to service a + new client request, the developer will insert pertinent + contextual information, such as the client id, client's IP + address, request parameters etc. into the <code>MDC</code>. Logback components, if appropriately configured, will automatically include this information in each log entry. @@ -100,10 +102,10 @@ logback-examples/src/main/java/chapter7/SimpleMDC.java)</a></em> <div class="source"><pre>package chapter7; +import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.slf4j.MDC; -import ch.qos.logback.classic.Logger; import ch.qos.logback.classic.PatternLayout; import ch.qos.logback.core.ConsoleAppender; @@ -120,10 +122,14 @@ ConsoleAppender<LoggingEvent> appender = new ConsoleAppender<LoggingEvent>(); appender.setLayout(layout); appender.start(); - Logger root = (Logger)LoggerFactory.getLogger("root"); - root.addAppender(appender); - // get a logger + // cast root logger to c.q.logback.classic.Logger so that we can attach an + // appender to it + ch.qos.logback.classic.Logger root = (ch.qos.logback.classic.Logger) LoggerFactory + .getLogger("root"); + root.addAppender(appender); + + // get another logger Logger logger = (Logger)LoggerFactory.getLogger(SimpleMDC.class); // We now put the last name @@ -173,18 +179,21 @@ <h3>Advanced Use</h3> <p> - Mapped Diagnostic Contexts shine brightest within client server architectures. - Typically, multiple clients will be served by multiple threads on the server. - Although the methods in the <code>MDC</code> class are static, - the diagnostic context is managed on a per thread basis, allowing each server - thread to bear a distinct <code>MDC</code> stamp. <code>MDC</code> operations - such as <code>put()</code> and <code>get()</code> affect the <code>MDC</code> - of the <em>current</em> thread only. The <code>MDC</code> in other threads remain - unaffected. Given that <code>MDC</code> information is managed on a - per thread basis, each thread will have its own copy of the <code>MDC</code>. - Thus, there is no need for the developer to worry about thread-safety or - synchronization when programming with the <code>MDC</code> because - it safely and transparently handles these issues. + Mapped Diagnostic Contexts shine brightest within client server + architectures. Typically, multiple clients will be served by + multiple threads on the server. Although the methods in the + <code>MDC</code> class are static, the diagnostic context is + managed on a per thread basis, allowing each server thread to + bear a distinct <code>MDC</code> stamp. <code>MDC</code> + operations such as <code>put()</code> and <code>get()</code> + affect only the <code>MDC</code> of the <em>current</em> thread, + and the children of the current thread. The <code>MDC</code> in + other threads remain unaffected. Given that <code>MDC</code> + information is managed on a per thread basis, each thread will + have its own copy of the <code>MDC</code>. Thus, there is no + need for the developer to worry about thread-safety or + synchronization when programming with the <code>MDC</code> + because it safely and transparently handles these issues. </p> <p> @@ -485,36 +494,35 @@ <h3>Automating access to the <code>MDC</code></h3> - <p> - As we've seen, the <code>MDC</code> is very useful when dealing with multiple - clients. In the case of a web application that manages user authentication, one - simple solution could be to set the user's name in the <code>MDC</code> and remove - it once the user logs out. Unfortunately, it is not always possible to achieve - reliable results using this technique. Since <code>MDC</code> is managing - information on a <em>per thread</em> basis, a server that recycles - threads might lead to false information contained in the <code>MDC</code>. - </p> - - <p> - To allow the information contained in the <code>MDC</code> to be correct - at all times when a request is processed, a solution might be to store the - username at the beginning of the process, and remove it at the end of - said process. A servlet - <a href="http://java.sun.com/javaee/5/docs/api/javax/servlet/Filter.html"> - <code>Filter</code></a> is a good tool to have at - hand in such case. - </p> - - <p> - By using a servlet filter, one can access the request, try to access - to relevant user information and store it in the <code>MDC</code>. - Then, after the process of creating the response, one just needs - to remove the user information from the <code>MDC</code>. + <p>As we've seen, the <code>MDC</code> is very useful when dealing + with multiple clients. In the case of a web application that + manages user authentication, one simple solution could be to set + the user's name in the <code>MDC</code> and remove it once the + user logs out. Unfortunately, it is not always possible to + achieve reliable results using this technique. Since + <code>MDC</code> manages data on a <em>per thread</em> basis, a + server that recycles threads might lead to false information + contained in the <code>MDC</code>. + </p> + + <p>To allow the information contained in the <code>MDC</code> to + be correct at all times when a request is processed, a possible + approach would be to store the username at the beginning of the + process, and remove it at the end of said process. A servlet <a + href="http://java.sun.com/javaee/5/docs/api/javax/servlet/Filter.html"> + <code>Filter</code></a> comes in handy in this case. + </p> + + <p>Within the servlet filter's <code>doFilter</code> method, we + can retreive the relevant user data through the request (or a + cookie threin), store it the <code>MDC</code>. Subsequent + processing by other filters and servlets will automatically + benefit from the MDC data that was stored previously. Finally, + when our servlet filter ragains control, we have an oppurtunity + to clean MDC data. </p> - <p> - Here is an implementation of such a filter: - </p> + <p>Here is an implementation of such a filter:</p> <em>Example 7.5: User servlet filter (<a href="../xref/chapter7/UserServletFilter.html"> logback-examples/src/main/java/chapter7/UserServletFilter.java)</a></em> @@ -547,7 +555,10 @@ FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; + Principal principal = req.getUserPrincipal(); + // Please note that we could have also used a cookie to + // retreive the user name if (principal != null) { String username = principal.getName(); @@ -587,17 +598,14 @@ If a user information is found, it is registered in the <code>MDC</code>. </p> - <p> - Once the filter chain has completed, the filter removes the user information - from the <code>MDC</code>. - </p> - - <p> - With this filter, the user information is present in the <code>MDC</code> only - the time it takes to process the request. The thread may be reused to process a - request for another user without risking to display false information in the - logs. + <p>Once the filter chain has completed, the filter removes the user + information from the <code>MDC</code>. </p> + + <p>The approach we just outlined sets MDC data only for the duration + of the request and only for the thread processing it. Other threads + are unaffected. Furthermore, any given thread will contain correct + MDC data any point in time.</p> <script src="../templates/footer.js"></script> </div> Modified: logback/trunk/logback-site/src/site/pages/news.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/news.html (original) +++ logback/trunk/logback-site/src/site/pages/news.html Wed Aug 29 23:59:52 2007 @@ -26,6 +26,18 @@ href="http://www.qos.ch/mailman/listinfo/logback-announce">logback announce</a> mailing list.</p> + + <hr width="80%" align="center" /> + + + <h3>XXth of September 2007 - Release of version 0.9.9</h3> + + <p>MDC data in now inherited by child threads. This behaviour was + already specified in the javadocs. The issue was raised by Martin + Benda in <a href="http://bugzilla.qos.ch/show_bug.cgi?id=64">bug + 64</a> and independently by Peter Huber. + </p> + <hr width="80%" align="center" />

1 0

[Bug 95] New: SMTPAppenderBase puts footers in wrong order
by bugzilla-daemon＠pixie.qos.ch 28 Aug '07

28 Aug '07

http://bugzilla.qos.ch/show_bug.cgi?id=95 Summary: SMTPAppenderBase puts footers in wrong order Product: logback-core Version: unspecified Platform: Macintosh OS/Version: Mac OS Status: NEW Severity: critical Priority: P1 Component: Appender AssignedTo: logback-dev(a)qos.ch ReportedBy: peter.royal(a)pobox.com SMTPAppenderBase puts the layout's file footer before the presentation footer. the presentation footer should come first. When used with the HTML layout, it results in invalid HTML (since the closing table tag is outside the closing html tag) -- Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

Time & Size Based RollingPolicy?
by Valeriy Pikulskyy 28 Aug '07

28 Aug '07

Hi everybody :) Is there any implementation of Time & Size Based RollingPolicy ?

1 0

svn commit: r1582 - logback/trunk/logback-core/src/main/java/ch/qos/logback/core/net
by noreply.ceki＠qos.ch 23 Aug '07

23 Aug '07

Author: ceki Date: Thu Aug 23 17:24:43 2007 New Revision: 1582 Modified: logback/trunk/logback-core/src/main/java/ch/qos/logback/core/net/TelnetAppender.java Log: minor import change Modified: logback/trunk/logback-core/src/main/java/ch/qos/logback/core/net/TelnetAppender.java ============================================================================== --- logback/trunk/logback-core/src/main/java/ch/qos/logback/core/net/TelnetAppender.java (original) +++ logback/trunk/logback-core/src/main/java/ch/qos/logback/core/net/TelnetAppender.java Thu Aug 23 17:24:43 2007 @@ -1,7 +1,5 @@ package ch.qos.logback.core.net; -import java.net.ServerSocket; - import ch.qos.logback.core.AppenderBase; public class TelnetAppender extends AppenderBase {

1 0

[Bug 94] New: Improve logging message of ContextJNDISelector
by bugzilla-daemon＠pixie.qos.ch 23 Aug '07

23 Aug '07

http://bugzilla.qos.ch/show_bug.cgi?id=94 Summary: Improve logging message of ContextJNDISelector Product: logback-classic Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P1 Component: Other AssignedTo: logback-dev(a)qos.ch ReportedBy: sdavids(a)gmx.de 14:08:09.153 [main] WARN root - The provided URL for contextmyContextName does not lead to a valid file First, there is a missing space between context and its name, second you should show which URL has been provided, e.g.: 14:08:09.153 [main] WARN root - The provided URL 'my/url/' for context myContextName does not lead to a valid file @@@@ Reproduce: http://logback.qos.ch/manual/contextSelector.html <env-entry> <description>JNDI logging context for this app</description> <env-entry-name>logback/context-name</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>myContextName</env-entry-value> </env-entry> <env-entry> <description>URL for configuring logback context</description> <env-entry-name>logback/configuration-resource</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>unknown.url</env-entry-value> </env-entry> -- Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 93] New: Typo in listener declaration; http://logback.qos.ch/manual/contextSelector.html
by bugzilla-daemon＠pixie.qos.ch 23 Aug '07

23 Aug '07

http://bugzilla.qos.ch/show_bug.cgi?id=93 Summary: Typo in listener declaration; http://logback.qos.ch/manual/contextSelector.html Product: logback-site Version: unspecified Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P1 Component: Documentation AssignedTo: logback-dev(a)qos.ch ReportedBy: sdavids(a)gmx.de missing > -- Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 1

svn commit: r1581 - logback/tags/release_0.9.8
by noreply.ceki＠qos.ch 22 Aug '07

22 Aug '07

Author: ceki Date: Wed Aug 22 22:02:26 2007 New Revision: 1581 Added: logback/tags/release_0.9.8/ - copied from r1580, /logback/trunk/ Log: tagging 0.9.8

1 0

svn commit: r1580 - logback/trunk/logback-site/src/site/pages
by noreply.ceki＠qos.ch 22 Aug '07

22 Aug '07

Author: ceki Date: Wed Aug 22 22:01:45 2007 New Revision: 1580 Modified: logback/trunk/logback-site/src/site/pages/news.html Log: typo fixes Modified: logback/trunk/logback-site/src/site/pages/news.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/news.html (original) +++ logback/trunk/logback-site/src/site/pages/news.html Wed Aug 22 22:01:45 2007 @@ -29,15 +29,15 @@ <hr width="80%" align="center" /> - <h3>20th of August 2007 - Release of version 0.9.8</h3> + <h3>22th of August 2007 - Release of version 0.9.8</h3> - <p>This version of logback syncronizes with SLF4J version 1.4.3. In + <p>This version of logback synchronizes with SLF4J version 1.4.3. In particular, logback now natively supports SLF4J's MDC API introduced in SLF4J version 1.4.1. If you are using SLF4J version 1.4.1 or later please make sure upgrade to logback version 0.9.8 or later. </p> - <p>Fixed a number of documentation releated bugs, in particular <a + <p>Fixed a number of documentation related bugs, in particular <a href="http://bugzilla.qos.ch/show_bug.cgi?id=90">bug 90</a> reported by Luc Maisonobe and <a href="http://bugzilla.qos.ch/show_bug.cgi?id=90">bug 88</a> reported

1 0