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

[JIRA] Created: (LBCLASSIC-268) ConcurrentModificationException in LogbackMDCAdapter
by Scott Stanton (JIRA) 20 Sep '11

20 Sep '11

ConcurrentModificationException in LogbackMDCAdapter ---------------------------------------------------- Key: LBCLASSIC-268 URL: http://jira.qos.ch/browse/LBCLASSIC-268 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.28 Environment: JRE 1.6.0_25, Windows 7 64-bit Reporter: Scott Stanton Assignee: Logback dev list Priority: Critical I'm seeing ConcurrentModificationException errors like the following: {panel} 011-05-23T04:53:31.997 | ERROR | Dispatch-001 | | | | OperationCaller | null | java.util.ConcurrentModificationException: null at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) ~[na:1.6.0_21] at java.util.HashMap$EntryIterator.next(HashMap.java:834) ~[na:1.6.0_21] at java.util.HashMap$EntryIterator.next(HashMap.java:832) ~[na:1.6.0_21] at java.util.HashMap.putAll(HashMap.java:523) ~[na:1.6.0_21] at ch.qos.logback.classic.util.LogbackMDCAdapter.put(LogbackMDCAdapter.java:76) ~[logback-classic.jar:na] at org.slf4j.MDC.put(MDC.java:112) ~[slf4j-api.jar:1.6.1] {panel} -- 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 3

[JIRA] Created: (LBCLASSIC-275) LoggingEvent casts to LogbackMDCAdapter without checking
by Chris Dolan (JIRA) 19 Sep '11

19 Sep '11

LoggingEvent casts to LogbackMDCAdapter without checking -------------------------------------------------------- Key: LBCLASSIC-275 URL: http://jira.qos.ch/browse/LBCLASSIC-275 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.28 Reporter: Chris Dolan Assignee: Logback dev list LoggingEvent has this code: // ugly but under the circumstances acceptable LogbackMDCAdapter logbackMDCAdapter = (LogbackMDCAdapter) MDC .getMDCAdapter(); mdcPropertyMap = logbackMDCAdapter.getPropertyMap(); I'm trying to build a logback implementation of the OSGi pax-logging-service (http://www.ops4j.org/projects/pax/logging/index.html) But I've got a problem that PAX exports org.slf4j.impl with their own MDC adapter that fails this cast. Theirs has the nice feature that the OSGi bundle context is automatically added to the MDC (at a performance cost, alas). I'd like to see LoggingEvent changed to something like the following for improved flexibility: MDCAdapter mdc = MDC.getMDCAdapter(); if (MDCAdaptor instanceof LogbackMDCAdapter) mdcPropertyMap = ((LogbackMDCAdapter)mdc).getPropertyMap(); else mdcPropertyMap = mdc.getCopyOfContextMap(); -- 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 6

[JIRA] Created: (LBCLASSIC-263) Logback Classic causes SecurityException
by NC (JIRA) 11 Sep '11

11 Sep '11

Logback Classic causes SecurityException ---------------------------------------- Key: LBCLASSIC-263 URL: http://jira.qos.ch/browse/LBCLASSIC-263 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.28 Reporter: NC Assignee: Logback dev list PackagingDataCalculator invokes Class.getClassLoader(). This method throws a SecurityException when running under a security manager and that manager denies access to the ClassLoader. I'm submitting a PackagingDataCalculator patch which wraps the getClassLoader() invocation in a doPrivileged block. This allows these calls to succeed when the getClassLoader RuntimePermission is granted to logback-classic. -- 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 8

[JIRA] Created: (LBCORE-79) FixedWindowRollingPolicy performs compression on the logging thread
by Szel Zoltan (JIRA) 02 Sep '11

02 Sep '11

FixedWindowRollingPolicy performs compression on the logging thread ------------------------------------------------------------------- Key: LBCORE-79 URL: http://jira.qos.ch/browse/LBCORE-79 Project: logback-core Issue Type: Improvement Components: Rolling Affects Versions: 0.9.13 Reporter: Szel Zoltan Assignee: Logback dev list Hi, the FixedWindowRollingPolicy performs the compression on the logging thread which can bring the application to halt, when compressing large files. Please consider modifing the FixedWindowRollingPolicy to perform the operation on a background thread as requested in LBCORE-48. Regards, 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

2 2

[JIRA] Created: (LBCORE-179) conversion word %ex length handling is off by one
by Michael Osipov (JIRA) 26 Aug '11

26 Aug '11

conversion word %ex length handling is off by one ------------------------------------------------- Key: LBCORE-179 URL: http://jira.qos.ch/browse/LBCORE-179 Project: logback-core Issue Type: Bug Components: Pattern Affects Versions: 0.9.26 Reporter: Michael Osipov Assignee: Logback dev list The %ex and %xEx define a stack trace length. The integer spec is somewhat faulty and misleading. First of all this is a stack trace depth imho and not length. Anyway, I was poking around with the SMTPAppender and wanted to include the sole exception message into the subject. The outcome was: 1. The docs do not define a valid interval for the integer value. You can only deduce from logic. 2. I defined %ex{short} and it included 2 lines of the stack trace. 3. I defined %ex{2} and it included 3 lines of the stack trace. 4. I defined %ex{0} and it included 1 line of the stack trace. 5. Defining any negative number omits the stack trace. But it does not make sense at all to have a negative stack trace depth. I checked also the source of the [https://github.com/ceki/logback/blob/master/logback-classic/src/main/java/c… converter], the lines 54 and 58 cause the problem. -- 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 3

[JIRA] Created: (LBCLASSIC-264) MDC of parent thread can be wiped from child thread
by Iwein Fuld (JIRA) 25 Aug '11

25 Aug '11

MDC of parent thread can be wiped from child thread --------------------------------------------------- Key: LBCLASSIC-264 URL: http://jira.qos.ch/browse/LBCLASSIC-264 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.28 Reporter: Iwein Fuld Assignee: Logback dev list In our web framework we're using the MDC, but because we use multiple rendering threads we need to copy context from one thread to another. With log4j this worked fine, with logback it doesn't. It seems that there is an issue at least with setContextMap, which can influence the MDC in other (non child) threads. I've reproduced one such issue in a small project: https://github.com/iwein/logback-testdrive Look at this testcase in particular: {code} @Test public void shouldCopyContextToOtherThread() throws Exception { final AtomicReference<Map> contextMap = new AtomicReference<Map>(); MDC.put("first", "Dorothy"); MDC.put("last", "Parker"); contextMap.set(MDC.getCopyOfContextMap()); //some context is set in a different thread Executors.newSingleThreadExecutor().execute(new Runnable() { public void run() { //not needed, but shouldn't break anything in the parent right? MDC.setContextMap(contextMap.get()); logger.info("Check enclosed."); } }); //If I don't do this I have lost my context. That seems wrong.. //MDC.setContextMap(contextMap.get()); logger.debug("The most beautiful two words in English."); } {code} I'll try to reproduce the issue with some sibling threads for the heck of it, but I think the above already illustrates the problem. -- 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 3

[JIRA] Created: (LBGENERAL-35) TimeBasedRollingWithArchiveRemovalTest failed
by Ralph Goers (JIRA) 25 Aug '11

25 Aug '11

TimeBasedRollingWithArchiveRemovalTest failed --------------------------------------------- Key: LBGENERAL-35 URL: http://jira.qos.ch/browse/LBGENERAL-35 Project: logback-general Issue Type: Sub-task Affects Versions: 0.9.17 Environment: Mac OSX Reporter: Ralph Goers Assignee: Logback dev list This is not a frequent occurence. ------------------------------------------------------------------------------- Test set: ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemovalTest ------------------------------------------------------------------------------- Tests run: 6, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.411 sec <<< FAILURE! montlyRollover(ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemovalTest) Time elapsed: 0.114 sec montlyRolloverOverManyPeriods(ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemovalTest) Time elapsed: 0.253 sec dailyRollover(ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemovalTest) Time elapsed: 0.058 sec dailyCronologRollover(ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemovalTest) Time elapsed: 0.108 sec dailySizeBasedRollover(ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemovalTest) Time elapsed: 0.454 sec dailyChronologSizeBasedRollover(ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemovalTest) Time elapsed: 0.417 sec <<< ERROR! java.util.concurrent.TimeoutException at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:228) at java.util.concurrent.FutureTask.get(FutureTask.java:91) at ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemovalTest.doRollover(TimeBasedRollingWithArchiveRemovalTest.java:194) at ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemovalTest.dailyChronologSizeBasedRollover(TimeBasedRollingWithArchiveRemovalTest.java:157) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) -- 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-116) SyslogAppender should support RFC 5424
by Ralph Goers (JIRA) 16 Aug '11

16 Aug '11

SyslogAppender should support RFC 5424 -------------------------------------- Key: LBCLASSIC-116 URL: http://jira.qos.ch/browse/LBCLASSIC-116 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.16 Environment: All Reporter: Ralph Goers Assignee: Logback dev list The SyslogAppender supports RFC 3164. RFC 5424 has been released with obsoletes RFC 3164. See http://www.ietf.org/rfc/rfc5424.txt. At the very least the format of the timestamp has been changed. Either the SyslogAppender should be enhanced to comply with RFC 5424 or a new SyslogAppender should be created which does. -- 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 19

[JIRA] Created: (LBCLASSIC-146) SysLog Appender and Line Breaks = :(
by Ingo Siebert (JIRA) 16 Aug '11

16 Aug '11

SysLog Appender and Line Breaks = :( -------------------------------------- Key: LBCLASSIC-146 URL: http://jira.qos.ch/browse/LBCLASSIC-146 Project: logback-classic Issue Type: Bug Components: appender Environment: Debian 4 Etch, 64 Bit (most likely all enviroments) Reporter: Ingo Siebert Assignee: Logback dev list I'm using the SysLog appender and it works well. But I've problems with line breaks, especially for exceptions. Every strack trace line is written as new SysLog-Entry. Example: Aug 11 20:25:21 192.168.33.11 app2-cas org.osgi.framework.BundleException: The bundle class path entry "patch.jar"..." Aug 11 20:25:21 192.168.33.11 app2-cas ^Iat org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassPathEntry(ClasspathManager.java:168) Aug 11 20:25:21 192.168.33.11 app2-cas ^Iat org.eclipse.osgi.baseadaptor.loader.ClasspathManager.buildClasspath(ClasspathManager.java:145) Aug 11 20:25:21 192.168.33.11 app2-cas ^Iat org.eclipse.osgi.baseadaptor.loader.ClasspathManager.initialize(ClasspathManager.java:79) ... That's quire annoying if you want to filter or highlight entries. I think it's major, because there isn't a good workaround to filter/highlight syslog files. I'm using Logback 0.9.13, but I thinks it still exists in the trunk. -- 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

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.29-9-g187647c
by git-noreply＠pixie.qos.ch 29 Jun '11

29 Jun '11

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Logback: the generic, reliable, fast and flexible logging framework.". The branch, master has been updated via 187647c5d3552e665cf365cf0fdfdf4023227b02 (commit) from bca247de428261b8c99c2a02cc4fc8ca580d78d2 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=187647c5d3552e665cf365cf… http://github.com/ceki/logback/commit/187647c5d3552e665cf365cf0fdfdf4023227… commit 187647c5d3552e665cf365cf0fdfdf4023227b02 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Wed Jun 29 12:34:45 2011 +0200 blurb about multiple email destinations separated by commas diff --git a/logback-site/src/site/pages/manual/appenders.html b/logback-site/src/site/pages/manual/appenders.html index f384485..72838df 100644 --- a/logback-site/src/site/pages/manual/appenders.html +++ b/logback-site/src/site/pages/manual/appenders.html @@ -1731,9 +1731,13 @@ public interface TriggeringPolicy<E> extends LifeCycle { <td>The email address of the recipient as a <em>pattern</em>. The pattern is evaluated anew with the triggering event as input for each outgoing email. Multiple - recipients can be specified by using several - <code><to></code> elements.</td> + recipients can be specified by separating the destination + addresses with commas. Alternatively, multiple recipients can + also be specified by using multiple <code><to></code> + elements. + </td> </tr> + <tr class="alt"> <td><b><span class="option">from</span></b></td> <td><code>String</code></td> diff --git a/logback-site/src/site/pages/news.html b/logback-site/src/site/pages/news.html index fb530d1..dedf41c 100644 --- a/logback-site/src/site/pages/news.html +++ b/logback-site/src/site/pages/news.html @@ -28,6 +28,22 @@ <hr width="80%" align="center" /> + <h3>July xxx, 2011 - Release of version 0.9.30</h3> + + <p>It is now possible to specify multiple destination addresses + separated by commas in the the <span class="option">to</span> + property of <code>SMTPAppender</code>. This fixes <a + href="http://jira.qos.ch/browse/LBCORE-213">LBCORE-213</a> + reported by Alexandre Garnier who also provided the relevant + patch. In previous versions of logback multiple destination + addresses could only be specified by using multiple <span + class="option">to</span> properties. As of version 0.9.30 both + comma separated addresses and multiple <span + class="option">to</span> properties are suported. + </p> + + <hr width="80%" align="center" /> + <h3>June 9th, 2011 - Release of version 0.9.29</h3> <p>Fixed <a ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/manual/appenders.html | 8 ++++++-- logback-site/src/site/pages/news.html | 16 ++++++++++++++++ 2 files changed, 22 insertions(+), 2 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0