- logback-dev - mailman3.qos.ch

[Bug 142] SyslogStartConverter specifies hour as 1-12 not 0-23
by bugzilla-daemon＠pixie.qos.ch 31 Mar '08

31 Mar '08

http://bugzilla.qos.ch/show_bug.cgi?id=142 ------- Comment #1 from peter.royal(a)pobox.com 2008-04-01 00:24 ------- Created an attachment (id=27) --> (http://bugzilla.qos.ch/attachment.cgi?id=27&action=view) patch to fix time format -- 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 141] New: introduce FlushableAppender
by bugzilla-daemon＠pixie.qos.ch 25 Mar '08

25 Mar '08

http://bugzilla.qos.ch/show_bug.cgi?id=141 Summary: introduce FlushableAppender Product: logback-core Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P3 Component: Appender AssignedTo: logback-dev(a)qos.ch ReportedBy: bruno.navert(a)morganstanley.com Suggest a new sub-interface of Appender: public interface FlushableAppender<E> extends Appender<E>, java.io.Flushable { } Then, WriterAppender could be defined to implement FlushableAppender, with this simple implementation: public void flush() throws IOException { writer.flush(); } This would allow manual flushing of the appenders. This is particularly useful when buffered IO is used, obviously. It allows, for instance, to manually flush all appenders when a request has been fully processed, ensuring that we retain the benefits of buffered IO while also having the full logs after request processing. Here's sample code I used to get all appenders (run once after Logback configuration): public static Set<Appender> getAllAppenders() { ContextSelector selector = StaticLoggerBinder.SINGLETON.getContextSelector(); LoggerContext loggerContext = selector.getLoggerContext(); Map<String, Appender> appenders = newHashMap(); // loop through all Loggers for ( Logger logger : loggerContext.getLoggerList() ) { // for each logger, loop through all its appenders Iterator iter = logger.iteratorForAppenders(); while ( iter.hasNext() ) { // appenders are uniquely identified by name, so store them in the Map thus // this will overwrite the same entry in the Map many times (with the same reference) Appender appender = ( Appender ) iter.next(); appenders.put( appender.getName(), appender ); } } return newHashSet( appenders.values() ); } The below bean is used in Spring, calling flush() forces all appenders to be flushed: public class LogbackFlushBean implements Flushable { protected final Logger log = LoggerFactory.getLogger( getClass() ); private final Collection<FlushableAppender> flushableAppenders = newLinkedList(); @PostConstruct public void loadFlushableAppenders() { for ( Appender appender : LogbackConfigurer.getAllAppenders() ) { if ( appender instanceof FlushableAppender ) { flushableAppenders.add( ( FlushableAppender ) appender ); } else { log.debug( "appender {} is not Flushable, skipping", appender.getName() ); } } } public void flush() throws IOException { for ( FlushableAppender appender : flushableAppenders ) { log.debug( "flushing appender {}", appender.getName() ); appender.flush(); } } } -- 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 140] New: logback.xml vs. logback-test.xml - conflicting information on website
by bugzilla-daemon＠pixie.qos.ch 24 Mar '08

24 Mar '08

http://bugzilla.qos.ch/show_bug.cgi?id=140 Summary: logback.xml vs. logback-test.xml - conflicting information on website Product: logback-core Version: unspecified Platform: PC OS/Version: Windows Status: NEW Severity: blocker Priority: P1 Component: Other AssignedTo: logback-dev(a)qos.ch ReportedBy: sapatel(a)nemours.org I am using latest version of logback. -------------------------------------------------------------------- <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> </dependency> -------------------------------------------------------------------- I found conflicting information on the logback website. http://logback.qos.ch/faq.html states "If a file called logback.xml is found in the classpath, then it is used. In case it is not found, a logback-test.xml file is searched, and used if available. If none of these files are available, logback uses its BasicConfigurator class to create a simple default configuration that will only log to the console." http://logback.qos.ch/manual/joran.html states " 1. Logback tries to find a file called logback-test.xml in the classpath. 2. If no such file is found, it checks for the file logback.xml. 3. In case neither file is found, logback configures itself automatically using the BasicConfigurator which will cause logging output to be directed on the console" > > I think that FAQ (http://logback.qos.ch/faq.html) is correct. If it is true, while running tests using Maven (mvn test) it uses "src/main/resources" (home of logback.xml) and "src/test/resources" (home of logback-test.xml). logback-test.xml will never override logback.xml. -- 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

svn commit: r1659 - logback/trunk/logback-access/src/test/java/ch/qos/logback/access/jetty
by noreply.ceki＠qos.ch 23 Mar '08

23 Mar '08

Author: ceki Date: Sun Mar 23 10:22:21 2008 New Revision: 1659 Modified: logback/trunk/logback-access/src/test/java/ch/qos/logback/access/jetty/JettyBasicTest.java Log: - import changes Modified: logback/trunk/logback-access/src/test/java/ch/qos/logback/access/jetty/JettyBasicTest.java ============================================================================== --- logback/trunk/logback-access/src/test/java/ch/qos/logback/access/jetty/JettyBasicTest.java (original) +++ logback/trunk/logback-access/src/test/java/ch/qos/logback/access/jetty/JettyBasicTest.java Sun Mar 23 10:22:21 2008 @@ -1,6 +1,6 @@ package ch.qos.logback.access.jetty; -import static org.junit.Assert.assertEquals; +import static org.junit.Assert.*; import java.io.OutputStreamWriter; import java.io.PrintWriter;

1 0

svn commit: r1658 - in logback/trunk/logback-site/src/site/pages: . manual
by noreply.ceki＠qos.ch 22 Mar '08

22 Mar '08

Author: ceki Date: Sat Mar 22 19:51:03 2008 New Revision: 1658 Modified: logback/trunk/logback-site/src/site/pages/faq.html logback/trunk/logback-site/src/site/pages/manual/joran.html Log: - Correcting incorrect text in the FAQ. The problem was mentioned in the user mailing list [1]. [1] http://www.qos.ch/pipermail/logback-user/2008-March/000410.html Modified: logback/trunk/logback-site/src/site/pages/faq.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/faq.html (original) +++ logback/trunk/logback-site/src/site/pages/faq.html Sat Mar 22 19:51:03 2008 @@ -101,15 +101,9 @@ </a> </dt> <dd> - If a file called logback.xml is found in the - classpath, then it is used. - - In case it is not found, a logback-test.xml file - is searched, and used if available. - - If none of these files are available, logback uses its - <code>BasicConfigurator</code> class to create a simple - default configuration that will only log to the console. + This question is answered in the <a + href="manual/joran.html#auto_configuration">relevant + section</a> of the logback manual. <table border="0"> <tr> Modified: logback/trunk/logback-site/src/site/pages/manual/joran.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/manual/joran.html (original) +++ logback/trunk/logback-site/src/site/pages/manual/joran.html Sat Mar 22 19:51:03 2008 @@ -47,8 +47,10 @@ configure your own applications. + <a name="auto_configuration"> + </a> <h2>Configuration in logback</h2> - + Inserting log requests into the application code requires a fair amount of planning and effort. Observation shows that approximately four percent of code is dedicated to

1 0

svn commit: r1657 - logback/trunk/logback-site/src/site/pages
by noreply.ceki＠qos.ch 22 Mar '08

22 Mar '08

Author: ceki Date: Sat Mar 22 19:45:01 2008 New Revision: 1657 Modified: logback/trunk/logback-site/src/site/pages/faq.html Log: - indetentation changes only Modified: logback/trunk/logback-site/src/site/pages/faq.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/faq.html (original) +++ logback/trunk/logback-site/src/site/pages/faq.html Sat Mar 22 19:45:01 2008 @@ -20,239 +20,185 @@ <div id="content"> <h2> - <a name="top">Logback Frequently Asked Questions</a> - </h2> - - - Logback Classic - - - <ol type="1"> - <li> - <a href="#setup_jetty"> - How can I use logback-classic with Jetty ? - </a> - </li> - <li> - <a href="#auto_config"> - How does the automatic configuration work? - </a> - </li> - <li> - <a href="#intercept_calls_tomcat"> - How can I intercept JCL calls in Tomcat? - </a> - </li> - <li> - <a href="#intercept_calls_jetty"> - How can I intercept JCL calls in Jetty ? - </a> - </li> - </ol> + <a name="top">Logback Frequently Asked Questions</a> + </h2> + + + Logback Classic + + + <ol type="1"> + <li> + <a href="#setup_jetty"> + How can I use logback-classic with Jetty ? + </a> + </li> + <li> + <a href="#auto_config"> + How does the automatic configuration work? + </a> + </li> + <li> + <a href="#intercept_calls_tomcat"> + How can I intercept JCL calls in Tomcat? + </a> + </li> + <li> + <a href="#intercept_calls_jetty"> + How can I intercept JCL calls in Jetty ? + </a> + </li> + </ol> - <div class="section"> - <h2>Logback Classic</h2> - <dl> - <dt> - <a name="setup_jetty"> - How can I use logback-classic with Jetty ? - </a> - </dt> - <dd> - - The Jetty application server uses SLF4J for its internal - logging. Here are the required steps to install logback - as SLF4J's underlaying implementation. - - - A few jars must be present in the - JETTY_HOME/lib - directory. - - - - Logback-classic is based on the SLF4J api. Therefore, - the - slf4j-api-VERSION.jar - jar must be present. This jar can be downloaded from the - <a href="http://www.slf4j.org/">SLF4J</a> - project. - - - Logback's own jars must also be present, namely - logback-core-VERSION.jar - and - logback-classic-VERSION.jar - . - - - - To configure logback-classic, a file called - logback.xml - should be placed in the - JETTY_HOME/resources - directory. You can find configuration samples in the - examples/src/chapter4/conf/ - directory, in the distribution of logback. - - <table border="0"> - <tr> - <td align="right"> - <a href="#top">[top]</a> - </td> - </tr> - </table> - <hr /> - </dd> - <dt> - <a name="auto_config"> - How does the automatic configuration work? - </a> - </dt> - <dd> - - If a file called - logback.xml - is found in the classpath, then it is used. - - - In case it is not found, a - logback-test.xml - file is searched, and used if available. - - - If none of these files are available, logback uses its - <code>BasicConfigurator</code> - class to create a simple default configuration that will - only log to the console. - - <table border="0"> - <tr> - <td align="right"> - <a href="#top">[top]</a> - </td> - </tr> - </table> - <hr /> - </dd> - <dt> - <a name="intercept_calls_tomcat"> - How can I intercept JCL calls in Tomcat? - </a> - </dt> - <dd> - - When a dependency of your webapp logs using Jakarta - Commons Logging (for example Struts), you can intercept - these calls and redirect them to logback. - - - This can be done by using - jcl104-over-slf4j.jar - , a module that is shipped with - <a href="http://www.slf4j.org">SLF4J</a> - . - - - If you have only one webapp, its - WEB-INF/lib - directory should already contain the logback jars, - namely - logback-core-VERSION.jar - , - logback-classic-VERSION.jar - and - slf4j-api-VERSION.jar - . A logback configuration file, named - logback.xml - should be placed in the - WEB-INF/classes/ - directory. - - - You now need to add - <code>jcl104-over-slf4j.jar</code> - to your - WEB-INF/lib - directory and remove - <code>commons-logging-1.0.4.jar</code> - . The logging that used to be directed to JCL should now - be handled by logback. - - - - In case several webapps share the logback jars, you - might place the previously mentionned jars in the - common/lib/ - directory of your Tomcat installation. The - logback.xml - file should then be placed in - common/classes - . - - <table border="0"> - <tr> - <td align="right"> - <a href="#top">[top]</a> - </td> - </tr> - </table> - <hr /> - </dd> - <dt> - <a name="intercept_calls_jetty"> - How can I intercept JCL calls in Jetty ? - </a> - </dt> - <dd> - - Using logback as the logging implementation of choice - for frameworks depending on JCL can also be done in - Jetty. - - - In case you have only one webapp, the required steps are - exactly the same as - <a href="#intercept_calls_tomcat"> - those needed in Tomcat - </a> - . - - - In case several webapps share the logback jars, you - might place the necessary jars in the - lib/ - directory of your Jetty installation. The - logback.xml - file should then be placed in the - resources/ - directory. - - - However, due to - <a - href="http://docs.codehaus.org/display/JETTY/Classloading"> - Jetty's internal Classloading mechanism - </a> - , the - logback-classic-VERSION.jar - and - slf4j-api-VERSION.jar - files should also be placed in the - WEB-INF/lib/ - directory of your webapps. - - <table border="0"> - <tr> - <td align="right"> - <a href="#top">[top]</a> - </td> + <div class="section"> + <h2>Logback Classic</h2> + <dl> + <dt> + <a name="setup_jetty"> + How can I use logback-classic with Jetty ? + </a> + </dt> + <dd> + The Jetty application server uses SLF4J for its internal + logging. Here are the required steps to install logback as + SLF4J's underlaying implementation. + + + A few jars must be present in the JETTY_HOME/lib + directory. + + + Logback-classic is based on the SLF4J api. Therefore, the + slf4j-api-VERSION.jar jar must be present. This jar + can be downloaded from the <a + href="http://www.slf4j.org/">SLF4J</a> project. + + Logback's own jars must also be present, namely + logback-core-VERSION.jar and + logback-classic-VERSION.jar . + + + To configure logback-classic, a file called + logback.xml should be placed in the + JETTY_HOME/resources directory. You can find + configuration samples in the + examples/src/chapter4/conf/ directory, in the + distribution of logback. + + + <table border="0"> + <tr> + <td align="right"> + <a href="#top">[top]</a> + </td> + </tr> + </table> + <hr /> + </dd> + <dt> + <a name="auto_config"> + How does the automatic configuration work? + </a> + </dt> + <dd> + If a file called logback.xml is found in the + classpath, then it is used. + + In case it is not found, a logback-test.xml file + is searched, and used if available. + + If none of these files are available, logback uses its + <code>BasicConfigurator</code> class to create a simple + default configuration that will only log to the console. + + <table border="0"> + <tr> + <td align="right"> + <a href="#top">[top]</a> + </td> </tr> - </table> - </dd> - </dl> - </div> - </div> + </table> + <hr /> + </dd> + <dt> + <a name="intercept_calls_tomcat"> + How can I intercept JCL calls in Tomcat? + </a> + </dt> + <dd> + When a dependency of your webapp logs using Jakarta Commons + Logging (for example Struts), you can intercept these calls + and redirect them to logback. + + This can be done by using jcl104-over-slf4j.jar , + a module that is shipped with <a + href="http://www.slf4j.org">SLF4J</a> . + + If you have only one webapp, its WEB-INF/lib + directory should already contain the logback jars, namely + logback-core-VERSION.jar , + logback-classic-VERSION.jar and + slf4j-api-VERSION.jar . A logback configuration file, + named logback.xml should be placed in the + WEB-INF/classes/ directory. + + You now need to add <code>jcl104-over-slf4j.jar</code> to + your WEB-INF/lib directory and remove + <code>commons-logging-1.0.4.jar</code> . The logging that used + to be directed to JCL should now be handled by logback. + + + In case several webapps share the logback jars, you might + place the previously mentionned jars in the + common/lib/ directory of your Tomcat + installation. The logback.xml file should then be + placed in common/classes . + + <table border="0"> + <tr> + <td align="right"> + <a href="#top">[top]</a> + </td> + </tr> + </table> + <hr /> + </dd> + <dt> + <a name="intercept_calls_jetty"> + How can I intercept JCL calls in Jetty ? + </a> + </dt> + <dd> + Using logback as the logging implementation of choice for + frameworks depending on JCL can also be done in Jetty. + + In case you have only one webapp, the required steps are + exactly the same as <a href="#intercept_calls_tomcat">those + needed in Tomcat</a>. + + In case several webapps share the logback jars, you might + place the necessary jars in the lib/ directory of + your Jetty installation. The logback.xml file should + then be placed in the resources/ directory. + + However, due to <a + href="http://docs.codehaus.org/display/JETTY/Classloading"> + Jetty's internal Classloading mechanism</a>, the + logback-classic-VERSION.jar and + slf4j-api-VERSION.jar files should also be placed in + the WEB-INF/lib/ directory of your webapps. + + <table border="0"> + <tr> + <td align="right"> + <a href="#top">[top]</a> + </td> + </tr> + </table> + </dd> + </dl> + </div> +</div>

1 0

[Bug 100] New: Serialization of objectArray in LoggingEvent does not always work
by bugzilla-daemon＠pixie.qos.ch 22 Mar '08

22 Mar '08

http://bugzilla.qos.ch/show_bug.cgi?id=100 Summary: Serialization of objectArray in LoggingEvent does not always work Product: logback-classic Version: unspecified Platform: PC URL: http://www.qos.ch/pipermail/logback-dev/2007- September/002169.html OS/Version: Other Status: NEW Severity: major Priority: P1 Component: Other AssignedTo: logback-dev(a)qos.ch ReportedBy: noreply.ceki(a)qos.ch I think this is happening: * Logback is sending a serialized LoggingEvent over the socket * the LoggingEvent has a reference to the foo.bar.Car instance * the Eclipse plugin receives the bytes over the wire and tries to deserialize the LoggingEvent, this fails because the foo.bar.Car class is not on the classpath. Resolution: I think the SocketAppender should only send the formattedMessage over the wire and not the argumentArray. In other words: argumentArray should be declared transient. Let's see what the LogBack developers think about that ... -- 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 19

[Bug 129] New: An <include> in an included file leads to out of memory
by bugzilla-daemon＠pixie.qos.ch 20 Mar '08

20 Mar '08

http://bugzilla.qos.ch/show_bug.cgi?id=129 Summary: An <include> in an included file leads to out of memory Product: logback-core Version: unspecified Platform: All OS/Version: All Status: NEW Severity: blocker Priority: P1 Component: Joran AssignedTo: logback-dev(a)qos.ch ReportedBy: mfranz(a)intershop.de Situation: 3 configuration files A.xml, B.xml and C.xml A includes B and B includes C This leads Joran to run into out of memory. The reason is in class ch.qos.logback.core.joran.action.IncludeAction The begin() method fills the instance variable recoder with events and adds them to the global list. But since there is only one instance of IncludeAction it adds the already added events from the first include a second time at the second include event. This leads to an almost endless loop. A not that severe effect is that if a single file contains multiple includes it executes the first include as often as the total number of includes is. To solve this for me clearing the event list at the end of the begin method worked well: public void begin(InterpretationContext ec, String name, Attributes attributes) throws ActionException { ... ec.getJoranInterpreter().addEvents(recorder.saxEventList); // This is my fix recorder.saxEventList.clear(); } -- 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 2

[Bug 139] New: LoggingEvent.formattedMessage is only initialized in c'tor.
by bugzilla-daemon＠pixie.qos.ch 20 Mar '08

20 Mar '08

http://bugzilla.qos.ch/show_bug.cgi?id=139 Summary: LoggingEvent.formattedMessage is only initialized in c'tor. Product: logback-classic Version: unspecified Platform: All OS/Version: All Status: NEW Severity: major Priority: P1 Component: Other AssignedTo: logback-dev(a)qos.ch ReportedBy: joern(a)huxhorn.de LoggingEvent.formattedMessage is only initialized if message and arguments are supplied during construction. If the default c'tor is used and message and arguments are provided using setMessage and setArgumentArray then formattedMessage will stay null. Instead, formattedMessage should be declared transient and the actual formatting should take place lazily during getFormattedMessage call. This would fix this problem, would increase general logging performance (formatting only if actually needed) and would decrease the size of serialized log events significantly while it would not change anything from the callers point of view. This is a follow-up of bug #100. -- 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 138] New: support looking up property files from classpath resources
by bugzilla-daemon＠pixie.qos.ch 20 Mar '08

20 Mar '08

http://bugzilla.qos.ch/show_bug.cgi?id=138 Summary: support looking up property files from classpath resources Product: logback-core Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P1 Component: Joran AssignedTo: logback-dev(a)qos.ch ReportedBy: bruno.navert(a)morganstanley.com Joran's support for property files (through PropertyAction) is useful, but it only reads filesystem files. It would be useful to be able to read classpath resources, that way the logback.xml file as well as its properties files would be located in the same place (in the class path). Furthermore, it would be useful for both resource and file lookups to perform system property resolution in the included file names. For instance: <substitutionProperty resource="config/logback/logback-${CONFIG_MODE}.properties"/> where CONFIG_MODE is a system property. In our environment this is set to something like DEV or QA or PROD, which would allow use of substitution properties that change based on the environment. -- 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