November 2011 - logback-dev

[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

[JIRA] Created: (LBCLASSIC-295) MarkerFilter doesn't recognize nested markers.
by Paolo Mazzoncini (JIRA) 29 May '12

29 May '12

MarkerFilter doesn't recognize nested markers. ---------------------------------------------- Key: LBCLASSIC-295 URL: http://jira.qos.ch/browse/LBCLASSIC-295 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.29 Environment: MacOsx, Jdk 1.6 update 26 Reporter: Paolo Mazzoncini Assignee: Logback dev list I was trying to use nested markers to organize my logs in a better (maybe) way. But the MarkerFilter (ch.qos.logback.classic.turbo.MarkerFilter) did not treat nested (or composite) markers as I expect. Here a test that shows this issue, this test can be appended to ch.qos.logback.classic.turbo.MarkerFilterTest: @Test public void testComposite(){ String compositeMarkerName = "compositeMarker"; Marker compositeMarker=MarkerFactory.getMarker(compositeMarkerName); compositeMarker.add(totoMarker); MarkerFilter mkt = new MarkerFilter(); mkt.setMarker(MARKER_NAME); mkt.setOnMatch("ACCEPT"); mkt.setOnMismatch("DENY"); mkt.start(); assertTrue(mkt.isStarted()); assertEquals(FilterReply.DENY, mkt.decide(null, null, null, null, null, null)); assertEquals(FilterReply.ACCEPT, mkt.decide(totoMarker, null, null, null, null, null)); assertEquals(FilterReply.ACCEPT, mkt.decide(compositeMarker, null, null, null, null, null)); } The solution that I found is pretty simple, here is the patch: diff --git a/logback-classic/src/main/java/ch/qos/logback/classic/turbo/MarkerFilter.java b/logback-classic/src/main/java/ch/qos/logback/classic/turbo/MarkerFilter.java index 8e133cb..434b035 100644 --- a/logback-classic/src/main/java/ch/qos/logback/classic/turbo/MarkerFilter.java +++ b/logback-classic/src/main/java/ch/qos/logback/classic/turbo/MarkerFilter.java @@ -47,7 +47,7 @@ public class MarkerFilter extends MatchingFilter { return onMismatch; } - if(markerToMatch.contains(marker)) { + if(marker.contains(markerToMatch)) { return onMatch; } else { return onMismatch; -- 1.7.5.4 -- 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: (LBCLASSIC-240) JNDIUtil.lookup always cast the JNDI lookup result to a String
by Maxence Dewil (JIRA) 22 May '12

22 May '12

JNDIUtil.lookup always cast the JNDI lookup result to a String -------------------------------------------------------------- Key: LBCLASSIC-240 URL: http://jira.qos.ch/browse/LBCLASSIC-240 Project: logback-classic Issue Type: Bug Components: joran Affects Versions: 0.9.27 Reporter: Maxence Dewil Assignee: Logback dev list JNDIUtil.lookup always cast the JNDI lookup result to a String. This method should support other object types like: java.net.URL, ... Description: 1. In our environment, we have declared a variable in Websphere that holds a URL. 2. We use an <insertFromJNDI /> tag. 3. Then the following exception is thrown: ERROR in ch.qos.logback.core.joran.spi.Interpreter@4:71 - RuntimeException in Action for tag [insertFromJNDI] java.lang.ClassCastException: java.net.URL incompatible with java.lang.String at java.lang.ClassCastException: java.net.URL incompatible with java.lang.String at at ch.qos.logback.classic.util.JNDIUtil.lookup(JNDIUtil.java:38) at at ch.qos.logback.classic.joran.action.InsertFromJNDIAction.begin(InsertFromJNDIAction.java:62) at at ch.qos.logback.core.joran.spi.Interpreter.callBeginAction(Interpreter.java:273) at at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:145) at at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:127) at at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:40) at at ch.qos.logback.core.joran.spi.Interpreter.play(Interpreter.java:332) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:126) -- 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 13

[JIRA] Created: (LBCLASSIC-176) Asynchronous File appender
by Konstantin Alexandrov (JIRA) 11 May '12

11 May '12

Asynchronous File appender -------------------------- Key: LBCLASSIC-176 URL: http://jira.qos.ch/browse/LBCLASSIC-176 Project: logback-classic Issue Type: New Feature Components: appender Reporter: Konstantin Alexandrov Assignee: Logback dev list Attachments: AsynchRollingFileAppender.java I implement asynch rolling file appender for my application, the reason is to decrease logging time in time critical part of application. This logger save up to 2 time logging time and decrease total IO concurrency. If you found this appender usable, then please include to distribution. 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 16

[JIRA] Created: (LBCLASSIC-180) XML/HTML tags haven't get escaped in HTMLLayout
by Xu Hui Hui (JIRA) 09 May '12

09 May '12

XML/HTML tags haven't get escaped in HTMLLayout ----------------------------------------------- Key: LBCLASSIC-180 URL: http://jira.qos.ch/browse/LBCLASSIC-180 Project: logback-classic Issue Type: Bug Components: layout Affects Versions: 0.9.18 Environment: Linux (Ubuntu), JavaSE 1.6 Reporter: Xu Hui Hui Assignee: Logback dev list View it here for a better looking: http://stackoverflow.com/questions/2069135/how-to-make-xml-get-escaped-in-h… I'm using logback (with slf4j) to do the logging, and I've got many XML content to be logged in both text files and HTML files (with HTMLLayout). However, logback just inserts the raw XML in the <TD> tags for the HTMLLayout, without any escaping or <pre> processing. Here is the snippet of my logback.xml: <appender name="ALL" class="ch.qos.logback.core.rolling.RollingFileAppender"> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>${DIR_ALL}/%d{yyyy-MM-dd}.%i.html</FileNamePattern> <TimeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <MaxFileSize>500KB</MaxFileSize> </TimeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> <layout class="ch.qos.logback.classic.html.HTMLLayout"> <pattern>%d{HH:mm:ss.SSS}%logger{1}%msg</pattern> <cssBuilder class="ch.qos.logback.classic.html.UrlCssBuilder"> <url>${CSS_HREF}</url> </cssBuilder> <title>Logs (ALL)</title> </layout> And the following is what I got: <td class="Message">(DemoCall) parsing response failed. Details: <call><action>getmessage</action></call> </td> What I'm expecting: <td class="Message">(DemoCall) parsing response failed. Details: <call><action>getmessage</action></call> </td> Or better wrap the above message with a <pre> tag. Do I need to extend the HTMLLayout to archive that? Or is it my job to do a StringEscapeUtils.escapeHTML(msg) for each log statement (I'm not going to do that, since there also is a file appender for which the escaping is not needed). 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

4 4