November 2010 - logback-dev

[JIRA] Created: (CONSPLUG-16) Make the Consol plugin available via an update site
by Szel Zoltan (JIRA) 28 Aug '12

28 Aug '12

Make the Consol plugin available via an update site --------------------------------------------------- Key: CONSPLUG-16 URL: http://jira.qos.ch/browse/CONSPLUG-16 Project: Console Plugin Issue Type: Task Components: other Reporter: Szel Zoltan Assignee: Logback dev list Hi, making the Consol plugin available via an Update Site would make the install of the plugin much easier for developers. Please consider creating one for this very useful plugin. Thanks in advance! Best Regardsm Zoltan Szel -- 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 6

[JIRA] Created: (CONSPLUG-26) Eclipse Helios Service Release 1 logback 0.9.26 does not work
by David Tkaczyk (JIRA) 28 Aug '12

28 Aug '12

Eclipse Helios Service Release 1 logback 0.9.26 does not work ------------------------------------------------------------- Key: CONSPLUG-26 URL: http://jira.qos.ch/browse/CONSPLUG-26 Project: Console Plugin Issue Type: Bug Components: other Environment: Linux 2.6.18-194.17.1.el5 x86_64 Reporter: David Tkaczyk Assignee: Logback dev list Plugin installs fine and "show views" creates a tab. <consolePlugin /> is added to logback.xml, but no logging ever occurs in this tab -- 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-212) Logback classic doesn't work with Tomcat
by Grzegorz Borkowski (JIRA) 21 Aug '12

21 Aug '12

Logback classic doesn't work with Tomcat ---------------------------------------- Key: LBCLASSIC-212 URL: http://jira.qos.ch/browse/LBCLASSIC-212 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.21 Reporter: Grzegorz Borkowski Assignee: Logback dev list Priority: Critical We have a web application running on Tomcat 6.0.26, which uses SLF4J for logging. Until now, we used SLF4J-Simple, and it worked very well. Now we try to switch to Logback, but we are not able to make it work. It works for logging one-line messages. But whenever any exception is thrown on server, which should print a stack trace, server hangs (It doesn't matter whether we actually print the stack trace in log or not). From what I was able to observe, it looks like it falls into endless loop, throwing "ClassNotFoundException: ch.qos.logback.classic.spi.ThrowableProxyUtil", which is caught and tried to be logged, which throws this exception again, and so on. I don't know why it throws this ClassNotFoundException - perhaps classloader issue? But even copying the logback jars to Tomcat's lib directory, I'm not able to run the application: than it has problems with starting up. Sometimes it freezes during loading web app, and often it helps to attach and detach debugger to Tomcat - it's a kind of magic... Anyway, it's horrendously painful, and I'm not able to make it work. Why such common setup (webapp on Tomcat) is not described in Logback documentation??? This is our configuration file : <configuration scan="true"> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">  <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n%ex</pattern> </encoder> </appender> <root level="info"> <appender-ref ref="STDOUT" /> </root> </configuration> (changing scan to "false" doesn't help. Also changing pattern to the one not containing "%ex" doesn't help) This is part of pom file related to logging: <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.6.0</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>0.9.21</version> <scope>runtime</scope> </dependency>  <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> <version>1.1.1</version> <scope>provided</scope> </dependency>  <dependency> <groupId>org.slf4j</groupId> <artifactId>jcl-over-slf4j</artifactId> <version>1.6.0</version> </dependency> If we change dependency from logback to SLF4J simple (1.6.0) than everything works smoothly, stacktraces are printed to console, no freezing, everything is perfect. -- 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 21

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