January 2012 - logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCLASSIC-242) Implement AsyncAppender
by Andrew Kowal (JIRA) 25 Jul '12

25 Jul '12

Implement AsyncAppender ----------------------- Key: LBCLASSIC-242 URL: http://jira.qos.ch/browse/LBCLASSIC-242 Project: logback-classic Issue Type: New Feature Components: appender Reporter: Andrew Kowal Assignee: Logback dev list Logback still lacks AsynAppender like the one in Log4j. This feature is *critical* for production use in heavy loaded applications. This is the show stopper for us to migrate from Log4j to Logback. Some time ago there was similar issue LBCLASSIC-20, but it was closed after implementing async compression. So this one is just about asynchronous appender decorator. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

4 4

[JIRA] Created: (LBCLASSIC-52) Allow multiple addresses for "to" property of SMTPAppender
by JIRA Administrator (JIRA) 11 Jul '12

11 Jul '12

Allow multiple addresses for "to" property of SMTPAppender ---------------------------------------------------------- Key: LBCLASSIC-52 URL: http://jira.qos.ch/browse/LBCLASSIC-52 Project: logback-classic Issue Type: Improvement Reporter: Andrey Utkin Assignee: Ceki Gulcu SMTPAppender don`t allow to specify multiple addresses in single "to" property. So that, it is (almost?) impossible to specify multiple "to" addresses via variable substitution. We should know exact number of addresses (variables) to specify appropriate quantity of <to> elements. But number of "to" addresses could be changed during application using and differ from customer to customer. So, IMFO it will be helpful to allow specifying multiple addresses in one <to> element. Multiple addresses could be separated by comma, for example (as comma is not valid character for email address). Right now we are using simple workaround. We subclass SMTPAppender and overwrite addTo(): {code} @Override public void addTo(String to) { StringTokenizer st = new StringTokenizer(to, ","); while(st.hasMoreTokens()) { super.addTo(st.nextToken().trim()); } } {code} This solution works just fine for us. May be it will be good to include this feature in core logback too. -- 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

3 6

[JIRA] Created: (LBCORE-242) log rollover should be configurable using %d multiple times in file name pattern
by Thomas Corte (JIRA) 09 Jul '12

09 Jul '12

log rollover should be configurable using %d multiple times in file name pattern -------------------------------------------------------------------------------- Key: LBCORE-242 URL: http://jira.qos.ch/browse/LBCORE-242 Project: logback-core Issue Type: Improvement Components: Rolling Affects Versions: 1.0.0 Reporter: Thomas Corte Assignee: Logback dev list Trying to configure a log rollover with logs being *rolled daily* and put into a directory named "yyyy-MM", i.e. one folder for each *month* containing that month's logs, I'm using the following appender config: {noformat} <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>app.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">  <fileNamePattern%d{yyyy-MM}/app.%d{yyyy-MM-dd}.log</fileNamePattern> </rollingPolicy> <encoder> <pattern>%d{"yyyy-MM-dd HH:mm:ss,SSS"} [%thread] %-5level %logger{36} - %msg%n%xEx</pattern> </encoder> </appender> {noformat} However, it seems as if the current logback implementation merely considers the first %d specification, which leads to a log rotation only once per month instead of the desired once per day frequency. I figure this is because via %d, the log rotation frequency and the file name pattern are somewhat tied together and seemingly can't be specified independently. It would be nice if either multiple %d specifiers would be supported, with an option to specify which one should be considered for the rollover period. Even better, it might be a good idea to support the rollover period to be specified separately and independently from the file name pattern; arguably, using the file name patterns for both is somewhat convenient, but violates the principle of "separation of concerns". -- 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

3 10

[JIRA] Created: (LBCLASSIC-272) Automatic MDC inheritance with thread pools cases false data printed in the log
by Lóránt Pintér (JIRA) 30 Jun '12

30 Jun '12

Automatic MDC inheritance with thread pools cases false data printed in the log ------------------------------------------------------------------------------- Key: LBCLASSIC-272 URL: http://jira.qos.ch/browse/LBCLASSIC-272 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.27 Environment: Applies to all Logback versions, specifically tested with Logback 0.9.27. Reporter: Lóránt Pintér Assignee: Logback dev list MDC inheritance when used in conjunction with a thread pool can turn out to be malicious. Consider the following in a web server where each line in the log contains the current user's name. 1. A web request comes in and processing is started on a thread 2. Authenticate the user (on original thread) 3. Put the user name into the MDC (on original thread) 4. Create some Runnable and pass it to a thread pool to be run in the background (on thread pool thread) Let's take a look at the logs that are printed from the Runnable created in step 4. Without automatic MDC inheritance (e.g. when using Log4J) these log lines will contain no user name. This can be good or bad, depending on what you want. If you do want the user name in these log lines, you can explicitly transfer the MDC from the originating thread to the thread pool thread. If you don't want to print the user name for background tasks, you are already done. If you have no access to the thread pool or the Runnables, you simply get no MDC information. However, if you do have automatic MDC inheritance (as with Logback), the log lines *will* contain a user name, but not from the originating thread. The thread pool thread will instead inherit its MDC from the first thread that executed a Runnable on it. This can never be what you want. You can correct this by transferring the original MDC manually, or clearing it explicitly inside your Runnable. But if you forget to do this, or you don't have access to the thread pool and the Runnables, you will end up with corrupt data in your logs. The latter can happen if you are using some third-party API that maintains its own thread pool. I can see two ways to fix this issue: 1) Make automatic MDC inhertance configurable from logback.xml. This is not a perfect solution: if you mix code that relies on MDC inheritance with code that relies on no MDC inheritance you will have no good value for this setting. 2) Remove the automatic MDC inheritance feature altogether. Instead, Logback (or even better: SLF4J) could provide some utility classes to wrap Runnable's and Callable's in something like this: {code} class MdcRetainingRunnable implements Runnable { private final Map context; public MdcRetainingRunnable { this.context = MDC.getCopyOfContextMap(); } @Override public void run() { Map originalContext = MDC.getCopyOfContextMap(); MDC.setContextMap(context); try { runWithMdc(); } finally { MDC.setContextMap(originalContext); } } abstract protected runWithMdc(); } {code} I would prefer solution #2 as it provides for the rule of least astonishment. -- 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

3 4

[JIRA] Created: (LBACCESS-29) Getting Java java.lang.ClassNotFound except with v1.0.0 & Jetty 7
by Ian Stewartson (JIRA) 22 Jun '12

22 Jun '12

Getting Java java.lang.ClassNotFound except with v1.0.0 & Jetty 7 ----------------------------------------------------------------- Key: LBACCESS-29 URL: http://jira.qos.ch/browse/LBACCESS-29 Project: logback-access Issue Type: Bug Affects Versions: 1.0.0 Environment: Linux RedHat 5.7 (2.6.18-274.3.1.el5) Jetty: jetty-7.5.1.v20110908 - 08 September 2011 java version "1.6.0_27" logback-access-1.0.0.jar logback-core-1.0.0.jar Reporter: Ian Stewartson Assignee: Logback dev list Have following installation instructions on Web page, however, get an exception when starting Jetty: 2011-11-28 09:35:50.809:WARN:oejx.XmlConfiguration:Config error at <Set name="requestLog">| <New id="requestLogImpl" class="ch.qos.logback.access.jetty.RequestLogImpl"/>| </Set> java.lang.ClassNotFoundException: ch.qos.logback.access.jetty.RequestLogImpl 2011-11-28 09:35:50.809:WARN:oejx.XmlConfiguration:Config error at <Ref id="RequestLogHandler"><Set name="requestLog">| <New id="requestLogImpl" class="ch.qos.logback.access.jetty.RequestLogImpl"/>| </Set></Ref> java.lang.ClassNotFoundException: ch.qos.logback.access.jetty.RequestLogImpl java.lang.reflect.InvocationTargetException jetty.xml contents:    <Set name="handler"> <New id="Handlers" class="org.eclipse.jetty.server.handler.HandlerCollection"> <Set name="handlers"> <Array type="org.eclipse.jetty.server.Handler"> <Item> <New id="Contexts" class="org.eclipse.jetty.server.handler.ContextHandlerCollection"/> </Item> <Item> <New id="DefaultHandler" class="org.eclipse.jetty.server.handler.DefaultHandler"/> </Item>  <Item> <New id="RequestLogHandler" class="org.eclipse.jetty.server.handler.RequestLogHandler"/> </Item> </Array> </Set> </New> </Set>    <Ref id="RequestLogHandler"> <Set name="requestLog"> <New id="requestLogImpl" class="ch.qos.logback.access.jetty.RequestLogImpl"> </New> </Set> </Ref> -- 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

[JIRA] Created: (LBCLASSIC-307) Logback is unable to recognize variable substitution for scanPeriod property
by Oh Chin Boon (JIRA) 12 Jun '12

12 Jun '12

Logback is unable to recognize variable substitution for scanPeriod property ---------------------------------------------------------------------------- Key: LBCLASSIC-307 URL: http://jira.qos.ch/browse/LBCLASSIC-307 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.30 Environment: Windows 7 Reporter: Oh Chin Boon Assignee: Logback dev list It seems like Logback is unable to recognize variable substitution for certain properties. For example the scanPeriod property: Logback configuration: <configuration scan="${scan:-true}" scanPeriod="${scan-interval:-10 minutes}"> Specified to take default value of 10 minutes of logback property is not defined. Logback properties: scan=true scan-interval=30 seconds This property should override the default configuration of 10 minutes. Logback error: java.lang.IllegalArgumentException: String value [${scan-interval:-10 minutes}] is not in the expected format. According to the Duration API, the duration format is correct. -- 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 2

[JIRA] Created: (LBCLASSIC-74) NullPointerException in Logger after container restart
by Manel Clos (JIRA) 11 Jun '12

11 Jun '12

NullPointerException in Logger after container restart ------------------------------------------------------ Key: LBCLASSIC-74 URL: http://jira.qos.ch/browse/LBCLASSIC-74 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.9 Environment: Eclipse 3.4, Java 5, Tomcat 5.5.26, plain JSP (no servlet) Reporter: Manel Clos Assignee: Logback dev list Hi, loggerContext in the Logger class is null after container restart. This will produce a NPE when trying to further use logback. java.lang.NullPointerException at ch.qos.logback.classic.Logger.callTurboFilters(Logger.java:775) at ch.qos.logback.classic.Logger.isDebugEnabled(Logger.java:630) at ch.qos.logback.classic.Logger.isDebugEnabled(Logger.java:613) at test.LogbackTest.testLogger(LogbackTest.java:15) -- 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

3 8

[JIRA] Created: (LBCORE-92) Implement AsyncAppender
by Cheenu (JIRA) 31 May '12

31 May '12

Implement AsyncAppender ----------------------- Key: LBCORE-92 URL: http://jira.qos.ch/browse/LBCORE-92 Project: logback-core Issue Type: Improvement Components: Appender Reporter: Cheenu Assignee: Logback dev list Please implement AsyncAppender as in log4j. http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/AsyncAppender.… Some flaws noted in the log4j appender (I don't agree with silently throwing away log messages being default though) http://glueclue.blogspot.com/2007/01/log4j-asyncappender-is-not-always_31.h… Referenced from #LBCLASSIC-20 Thanks -- 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

5 6

[JIRA] Created: (LBCLASSIC-177) Provide an appender similar to log4js AsyncAppender
by Torsten Juergeleit (JIRA) 31 May '12

31 May '12

Provide an appender similar to log4js AsyncAppender --------------------------------------------------- Key: LBCLASSIC-177 URL: http://jira.qos.ch/browse/LBCLASSIC-177 Project: logback-classic Issue Type: New Feature Components: appender Affects Versions: unspecified Reporter: Torsten Juergeleit Assignee: Logback dev list We're using log4j successfully in financial B2B / B2C web applications for years. Now we would like to adopt Logback but therefore we need support for an asynchronous appender decorator like log4js AsyncAppender. Attached you can find my take on this kind of appender cobbled together from ideas and code from various places: * http://logging.apache.org/log4j/1.2/xref/org/apache/log4j/AsyncAppender.html * http://jira.qos.ch/browse/LBCLASSIC-20 * http://jira.qos.ch/browse/LBCLASSIC-176 * http://www.simonsite.org.uk/ -- 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

5 12

[JIRA] Created: (LBCORE-137) PatternLayout does not really respect ISO8601 for date time
by Brice Dutheil (JIRA) 30 May '12

30 May '12

PatternLayout does not really respect ISO8601 for date time ----------------------------------------------------------- Key: LBCORE-137 URL: http://jira.qos.ch/browse/LBCORE-137 Project: logback-core Issue Type: Improvement Components: Layout Affects Versions: 0.9.19 Environment: irrelevant here Reporter: Brice Dutheil Assignee: Logback dev list Using the default "%d" "%date" or %d{ISO8601} does not output a correct ISO 8601 formatted date and time representation. Indeed there is a space between the date and the time, as the specification says having a space separator means there two fields : a 'date field' and a 'time field'. The specification consider this as acceptable for human reading though. However when processing logs it might cause some trouble to effectively parse the fields, especially when correlating logs from different applications. For now we have workarounds, but it seems reasonable to have a correct ISO8601 formatting. The correct ISO8601 representation for a 'date and time field' is to have the T indicator, for example '2007-03-01T13:00:00Z'. The workaround for now is to write ourself the correct ISO8601 pattern. Oh and by the way the timezone formatting options in the SimpleDateFormat are incomplete. The JodaTime format class org.joda.time.format.ISODateTimeFormat worth a look on this matter. Anyway date and time related classes in the JDK are not known for being the best at what they do. This problem is also found in log4j. An excerpt of the specification is documented on wikipedia. http://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations -- 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

3 2