March 2011 - logback-dev - mailman3.qos.ch

[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-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

[JIRA] Created: (LBCLASSIC-159) Invalid multiple configuration file warning
by Hontvári József (JIRA) 08 May '12

08 May '12

Invalid multiple configuration file warning ------------------------------------------- Key: LBCLASSIC-159 URL: http://jira.qos.ch/browse/LBCLASSIC-159 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.917 Environment: Resin webapp Reporter: Hontvári József Assignee: Logback dev list I receive strange warnings in the status info. It says that logback.xml, which in this case comes from a file and not from the classpath, occurs multiple times. The file is specifies and logged using absolute path, so even relative paths cannot cause the warning. Logback configuration file is specified by the system property "logback.configurationFile". It is done by the Resin application server, somehow it is able to supply different properties for different web applications. I don't think this is important, however. Maybe I am doing something wrong, but at least the message doesn't help. 20:36:34,236 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [file:/C:/Progra~1/mireka/conf/logback.xml] at [file:/C:/Progra~1/mireka/conf/logback.xml] 20:36:34,236 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:/C:/Progra~1/mireka/conf/logback.xml] occurs multiple times on the classpath. 20:36:34,236 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:/C:/Progra~1/mireka/conf/logback.xml] occurs at [file:/C:/Progra~1/mireka/conf/logback.xml] 20:36:34,236 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:/C:/Progra~1/mireka/conf/logback.xml] occurs at [file:/C:/Progra~1/mireka/conf/logback.xml] 20:36:34,236 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:/C:/Progra~1/mireka/conf/logback.xml] occurs at [file:/C:/Progra~1/mireka/conf/logback.xml] -- 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 16

[JIRA] Created: (LBCLASSIC-256) java.util.logging propagated level changes are lost because of race condition with garbage collection
by Samuel Stanojevic (JIRA) 03 May '12

03 May '12

java.util.logging propagated level changes are lost because of race condition with garbage collection ----------------------------------------------------------------------------------------------------- Key: LBCLASSIC-256 URL: http://jira.qos.ch/browse/LBCLASSIC-256 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.28 Environment: win7 64-bit, bootstrapped in a Tomcat server Reporter: Samuel Stanojevic Assignee: Logback dev list Attachments: LevelChangePropagator.java I have bootstrapped logback in my Tomcat server, and have setup JUL to redirect logging requests to SLF4J by adding the following in my logging.properties: .handlers = org.slf4j.bridge.SLF4JBridgeHandler Anyways, my setup works pretty nicely. The problem is when I try to activate the JUL LevelChangePropagator, the info doesn't quite propagate as expected. Here is my config: <configuration debug="true"> <contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator"> <resetJUL>true</resetJUL> </contextListener> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">  <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern> </encoder> <target>System.out</target> </appender> <root level="ERROR"> <appender-ref ref="STDOUT" /> </root> <logger name="test.propagation" level="TRACE"/>  </configuration> The problem is that if my app tries to do: java.util.logging.Logger.getLogger("test.propagation").fine("hello world"); ..., it doesn't print. I have confirmed that the bug is because, even though the LevelChangePropagator class does propagate the level change info to JUL, it fails to keep a strong reference to the logger that it just changed. By not keeping a strong reference, and because the JUL LogManager only keeps WeakReferences to loggers, then the GC has time to clear out the change before the app's first attempt to use the logger. (see java.util.logging.LogManager#addLogger where the javadoc says "The application should retain its own reference to the Logger object to avoid it being garbage collected. The LogManager may only retain a weak reference") To test my hunch, I patched the LevelChangePropagator class by adding a global hashset of java.util.logging.Logger, and I systematically add the loggers to the hashset in the method "propagate(logger,level)". After this patch, my logging started working as expected. My fix may not be the best, and may have implications that I did not think about, but I think something along those lines needs to be done to fix the bug. -- 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 7

[JIRA] Created: (LBCLASSIC-234) CLONE -Excessive synchronization in ReconfigureOnChangeFilter.decide
by uri unger (JIRA) 25 Apr '12

25 Apr '12

CLONE -Excessive synchronization in ReconfigureOnChangeFilter.decide -------------------------------------------------------------------- Key: LBCLASSIC-234 URL: http://jira.qos.ch/browse/LBCLASSIC-234 Project: logback-classic Issue Type: Bug Affects Versions: 0.917 Reporter: uri unger Assignee: Ceki Gulcu The synchronization in ReconfigureOnChangeFilter.decide hurts scalability. It seems unnecessary to serialize the code in changeDetected -- it should be possible to use atomic updates of nextCheck and lastModified and only serialize the actual reconfiguration. -- 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

6 18

[JIRA] Created: (LBCORE-169) RollingFileAppender/TimeBasedRollingPolicy failing to ZIP files in different directory
by Tomasz Nurkiewicz (JIRA) 24 Apr '12

24 Apr '12

RollingFileAppender/TimeBasedRollingPolicy failing to ZIP files in different directory -------------------------------------------------------------------------------------- Key: LBCORE-169 URL: http://jira.qos.ch/browse/LBCORE-169 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.24 Reporter: Tomasz Nurkiewicz Assignee: Logback dev list When using ZIP feature to compress old log files, Logback does not allow to put ZIP files in different directory like in this example: <file>logs\server.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>logs\arch\server.%d{yyyy-MM-dd_HHmm}.log.zip</fileNamePattern> </rollingPolicy> Running the attached test maven project (it takes 1 minute to run) will create server.log3560979839057.tmp (or similar) temporary file instead of ZIP file in /arch subdirectory (preferably this directory should be created if not exists). If fileNamePattern in rollingPolicy is changed to: "logs\server.%d{yyyy-MM-dd_HHmm}.log.zip" everything works as expected. The root of this issue is to be able to automatically ZIP files AND archive them in different directory. It would be great to be able to use date placeholders in folder names, for instance: <fileNamePattern>logs\arch-%d{yyyy-MM}\server.%d{yyyy-MM-dd_HHmm}.log.zip</fileNamePattern> so that Logback would automatically create folders for each month with ZIPped files. -- 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

8 9