- logback-dev - mailman3.qos.ch

svn commit: r1585 - in logback/trunk: logback-access logback-classic logback-core logback-core/lib
by noreply.ceki＠qos.ch 06 Sep '07

06 Sep '07

Author: ceki Date: Thu Sep 6 15:48:37 2007 New Revision: 1585 Removed: logback/trunk/logback-core/lib/ Modified: logback/trunk/logback-access/pom.xml logback/trunk/logback-classic/pom.xml logback/trunk/logback-core/pom.xml Log: - removing retroweaver support - removing logback-core/lib directory Modified: logback/trunk/logback-access/pom.xml ============================================================================== --- logback/trunk/logback-access/pom.xml (original) +++ logback/trunk/logback-access/pom.xml Thu Sep 6 15:48:37 2007 @@ -129,6 +129,7 @@ </executions> </plugin> +  </plugins> </build> Modified: logback/trunk/logback-classic/pom.xml ============================================================================== --- logback/trunk/logback-classic/pom.xml (original) +++ logback/trunk/logback-classic/pom.xml Thu Sep 6 15:48:37 2007 @@ -137,6 +137,7 @@ </configuration> </plugin> +  + </plugins> </build> Modified: logback/trunk/logback-core/pom.xml ============================================================================== --- logback/trunk/logback-core/pom.xml (original) +++ logback/trunk/logback-core/pom.xml Thu Sep 6 15:48:37 2007 @@ -95,6 +95,7 @@ </executions> </plugin> +  + </plugins> </build> </project> \ No newline at end of file

1 0

svn commit: r1584 - logback/trunk/logback-site/src/site/pages/manual
by noreply.ceki＠qos.ch 06 Sep '07

06 Sep '07

Author: ceki Date: Thu Sep 6 15:47:18 2007 New Revision: 1584 Modified: logback/trunk/logback-site/src/site/pages/manual/appenders.html Log: ongoing work on documentation Modified: logback/trunk/logback-site/src/site/pages/manual/appenders.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/manual/appenders.html (original) +++ logback/trunk/logback-site/src/site/pages/manual/appenders.html Thu Sep 6 15:47:18 2007 @@ -43,11 +43,11 @@ <h2>What is an Appender?</h2> - - Logback delegates the task of writing a logging event to appenders. - Appenders must implement the - <a href="../xref/ch/qos/logback/core/Appender.html"><code>ch.qos.logback.core.Appender</code></a> interface. - The salient methods of this interface are summarized below: + Logback delegates the task of writing a logging event to + components called appenders. Appenders must implement the <a + href="../xref/ch/qos/logback/core/Appender.html"><code>ch.qos.logback.core.Appender</code></a> + interface. The salient methods of this interface are summarized + below: <div class="source"><pre>package ch.qos.logback.core; @@ -67,28 +67,35 @@ }</pre></div> - Most of the methods in the <code>Appender</code> interface are made of setter - and getter methods. A notable exception is the <code>doAppend()</code> - method taking an Object instance as its only parameter. - This method is perhaps the most important in the logback framework. - It is responsible for outputting the logging events in a suitable format - to the appropriate output device. Appenders are named entities. - This ensures that they can be referenced by name, a quality confirmed - to be especially significant in configuration scripts. - An appender can contain multiple filters, thus the <code>Appender</code> - interface extending the <code>FilterAttachable</code> interface. - Filters are discussed in detail in a subsequent chapter. + Most of the methods in the <code>Appender</code> interface are + made of setter and getter methods. A notable exception is the + <code>doAppend()</code> method taking an object instance of type + E as its only parameter. The actual type of E + would vary depending on the logback module. Within the + logback-classic module E would be of type <a + href="../apidocs/ch/qos/logback/classic/spi/LoggingEvent.html">LoggingEvent</a> + and within the logback-access module it would be of type <a + href="../apidocs/ch/qos/logback/access/spi/AccessEvent.html">AccessEvent</a>. + The <code>doAppend()</code> method is perhaps the most important + in the logback framework. It is responsible for outputting the + logging events in a suitable format to the appropriate output + device. Appenders are named entities. This ensures that they can + be referenced by name, a quality confirmed to be especially + significant in configuration scripts. An appender can contain + multiple filters, thus the <code>Appender</code> interface + extending the <code>FilterAttachable</code> interface. Filters + are discussed in detail in a subsequent chapter. - Appenders are ultimately responsible for outputting logging events. - However, they may delegate the actual formatting of the event to a - <code>Layout</code> object. - Each layout is associated with one and only one appender, referred to - as the containing appender. Some appenders have a built-in or fixed - event format, such that they do not require a layout. For example, the - <code>SocketAppender</code> simply serialize logging events before - transmitting them over the wire. + Appenders are ultimately responsible for outputting logging + events. However, they may delegate the actual formatting of the + event to a <code>Layout</code> object. Each layout is associated + with one and only one appender, referred to as the owning + appender. Some appenders have a built-in or fixed event format, + such that they do not require a layout. For example, the + <code>SocketAppender</code> simply serializes logging events + before transmitting them over the wire. <a name="AppenderBase"></a> @@ -96,16 +103,17 @@ The <a href="../xref/ch/qos/logback/core/AppenderBase.html"> - <code>ch.qos.logback.core.AppenderBase</code></a> class is an abstract - class implementing the <code>Appender</code> interface. - It provides basic functionality shared by all appenders, - such as methods for getting or setting their name, their started status, - their layout and their filters. - It is the super-class of all appenders shipped with logback. - Although an abstract class, <code>AppenderBase</code> actually implements the - <code>doAppend()</code> method in the <code>Append</code> interface. - Perhaps the clearest way to discuss <code>AppenderBase</code> class is by - presenting a bit of its actual source code. + <code>ch.qos.logback.core.AppenderBase</code></a> class is an + abstract class implementing the <code>Appender</code> interface. + It provides basic functionality shared by all appenders, such as + methods for getting or setting their name, their activation + status, their layout and their filters. It is the super-class of + all appenders shipped with logback. Although an abstract class, + <code>AppenderBase</code> actually implements the + <code>doAppend()</code> method in the <code>Append</code> + interface. Perhaps the clearest way to discuss + <code>AppenderBase</code> class is by presenting an excerpt of + actual source code. <div class="source"><pre>public synchronized void doAppend(E eventObject) { @@ -157,21 +165,24 @@ - The first statement of the <code>doAppend()</code> method, once the <code>try</code> block - is reached, is to check whether the <code>started</code> field is true. - If it is not, <code>doAppend()</code> will send a warning message and return. - In other words, once stopped, it is impossible to write to a closed appender. - <code>Appender</code> objects implement the <code>LifeCycle</code> interface, - which implies that they implement <code>start()</code>, <code>stop()</code> - and <code>isStarted()</code> methods. After setting all the options of an appender, - Joran, logback's configuration framework, calls the <code>start()</code> - method to signal the appender to bind or activate its options. - Indeed, depending on the appender, certain options cannot be activated because - of interferences with other options, or appenders can even not start at all if - some options are missing. - For example, since file creation depends on truncation mode, - <code>FileAppender</code> cannot act on the value of its <code>File</code> option - until the value of the Append option is also known for certain. + The first statement of the <code>doAppend()</code> method, once + the <code>try</code> block is reached, is to check whether the + <code>started</code> field is true. If it is not, + <code>doAppend()</code> will send a warning message and return. + In other words, once stopped, it is impossible to write to a + closed appender. <code>Appender</code> objects implement the + <code>LifeCycle</code> interface, which implies that they + implement <code>start()</code>, <code>stop()</code> and + <code>isStarted()</code> methods. After setting all the options of + an appender, Joran, logback's configuration framework, calls the + <code>start()</code> method to signal the appender to bind or + activate its options. Indeed, depending on the appender, certain + options cannot be activated because of interferences with other + options, or appenders can even not start at all if some options + are missing. For example, since file creation depends on + truncation mode, <code>FileAppender</code> cannot act on the value + of its <code>File</code> option until the value of the Append + option is also known for certain.

1 0

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 Mapped Diagnostic Context, 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 Mapped Diagnostic Context, 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. * * The MDC is managed on a per thread basis. 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. * * * If the current thread does not have a context map it is created as a side @@ -40,25 +40,26 @@ * * * 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 @@ * * * 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 diagnostic context that can be subsequently retrieved by certain logback components. The <code>MDC</code> manages contextual - information on a per thread basis. 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 per thread basis. A child thread * + automatically inherits a copy 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> <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> - 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 current 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 current 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. @@ -485,36 +494,35 @@ <h3>Automating access to the <code>MDC</code></h3> - - 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 per thread basis, a server that recycles - threads might lead to false information contained in the <code>MDC</code>. - - - - 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. - - - - 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>. + 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 per thread basis, a + server that recycles threads might lead to false information + contained in the <code>MDC</code>. + + + 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. + + + 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. - - Here is an implementation of such a filter: - + Here is an implementation of such a filter: Example 7.5: User servlet filter (<a href="../xref/chapter7/UserServletFilter.html"> logback-examples/src/main/java/chapter7/UserServletFilter.java)</a> @@ -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>. - - Once the filter chain has completed, the filter removes the user information - from the <code>MDC</code>. - - - - 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. + Once the filter chain has completed, the filter removes the user + information from the <code>MDC</code>. + + 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. <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. + + <hr width="80%" align="center" /> + + + <h3>XXth of September 2007 - Release of version 0.9.9</h3> + + 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. + + <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