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

[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

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

29 Aug '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 f47630842482beb41d38cc1c45a96088f09bcd82 (commit) from b336c697267f83057e708e56006f4c3322320b5c (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=f47630842482beb41d38cc1c… http://github.com/ceki/logback/commit/f47630842482beb41d38cc1c45a96088f09bc… commit f47630842482beb41d38cc1c45a96088f09bcd82 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Mon Aug 29 19:27:01 2011 +0200 migrating test to scala diff --git a/logback-core/src/test/scala/ch/qos/logback/core/rolling/TimeBasedRollingWithArchiveRemoval_STest.scala b/logback-core/src/test/scala/ch/qos/logback/core/rolling/TimeBasedRollingWithArchiveRemoval_STest.scala new file mode 100644 index 0000000..13bbac2 --- /dev/null +++ b/logback-core/src/test/scala/ch/qos/logback/core/rolling/TimeBasedRollingWithArchiveRemoval_STest.scala @@ -0,0 +1,135 @@ +package ch.qos.logback.core.rolling + +import org.junit.{Before, Test} +import ch.qos.logback.core.{Context, ContextBase} +import ch.qos.logback.core.testUtil.RandomUtil +import ch.qos.logback.core.util.CoreTestConstants +import org.junit.Assert._ +import ch.qos.logback.core.encoder.EchoEncoder +import java.util.concurrent.TimeUnit +import java.io.{FileFilter, File} +import collection.mutable.ListBuffer + +/** + * Created by IntelliJ IDEA. + * User: ceki + * Date: 29.08.11 + * Time: 18:08 + * To change this template use File | Settings | File Templates. + */ + +class TimeBasedRollingWithArchiveRemoval_STest { + var context: Context = new ContextBase + var encoder: EchoEncoder[AnyRef] = new EchoEncoder[AnyRef] + + val MONTHLY_DATE_PATTERN: String = "yyyy-MM" + + val MILLIS_IN_MINUTE: Long = 60 * 1000 + val MILLIS_IN_HOUR: Long = 60 * MILLIS_IN_MINUTE + val MILLIS_IN_DAY: Long = 24 * MILLIS_IN_HOUR + val MILLIS_IN_MONTH: Long = ((365.0 / 12) * MILLIS_IN_DAY).asInstanceOf[Long] + + var diff: Int = RandomUtil.getPositiveInt + var randomOutputDir: String = CoreTestConstants.OUTPUT_DIR_PREFIX + diff + "/" + var slashCount: Int = 0 + + // by default tbfnatp is an instance of DefaultTimeBasedFileNamingAndTriggeringPolicy + var tbfnatp: TimeBasedFileNamingAndTriggeringPolicy[AnyRef] = new DefaultTimeBasedFileNamingAndTriggeringPolicy[AnyRef] + + @Before def setUp { + context.setName("test") + } + + def computeSlashCount(datePattern: String): Int = { + if (datePattern == null) 0 + else datePattern.foldLeft(0)((count, c) => if (c == '/') count + 1 else count) + } + + @Test + def montlyRollover { + slashCount = computeSlashCount(MONTHLY_DATE_PATTERN) + doRollover(randomOutputDir + "clean-%d{" + MONTHLY_DATE_PATTERN + "}.txt", MILLIS_IN_MONTH, 20, 20 * 3) + check(expectedCountWithoutFolders(20)) + } + + def addTime(currentTime: Long, timeToWait: Long): Long = { + return currentTime + timeToWait + } + + def waitForCompression(tbrp: TimeBasedRollingPolicy[AnyRef]): Unit = { + if (tbrp.future != null && !tbrp.future.isDone) { + tbrp.future.get(800, TimeUnit.MILLISECONDS) + } + } + + def doRollover(fileNamePattern: String, periodDurationInMillis: Long, maxHistory: Int, simulatedNumberOfPeriods: Int): Unit = { + var currentTime: Long = System.currentTimeMillis + var rfa: RollingFileAppender[AnyRef] = new RollingFileAppender[AnyRef] + rfa.setContext(context) + rfa.setEncoder(encoder) + var tbrp: TimeBasedRollingPolicy[AnyRef] = new TimeBasedRollingPolicy[AnyRef] + tbrp.setContext(context) + tbrp.setFileNamePattern(fileNamePattern) + tbrp.setMaxHistory(maxHistory) + tbrp.setParent(rfa) + tbrp.timeBasedFileNamingAndTriggeringPolicy = tbfnatp + tbrp.timeBasedFileNamingAndTriggeringPolicy.setCurrentTime(currentTime) + tbrp.start + rfa.setRollingPolicy(tbrp) + rfa.start + var ticksPerPeriod: Int = 512 + var runLength = simulatedNumberOfPeriods * ticksPerPeriod + + for (i <- 0 to runLength) { + rfa.doAppend("Hello ----------------------------------------------------------" + i) + tbrp.timeBasedFileNamingAndTriggeringPolicy.setCurrentTime(addTime(tbrp.timeBasedFileNamingAndTriggeringPolicy.getCurrentTime, periodDurationInMillis / ticksPerPeriod)) + if (i % (ticksPerPeriod / 2) == 0) { + waitForCompression(tbrp) + } + + } + waitForCompression(tbrp) + rfa.stop + } + + def expectedCountWithoutFolders(maxHistory: Int): Int = { + return maxHistory + 1 + } + + def findFoldersInFolderRecursively(dir: File, fileList: ListBuffer[File]) { + if (dir.isDirectory) { + var `match` : Array[File] = dir.listFiles(new FileFilter { + def accept(f: File): Boolean = { + return f.isDirectory + } + }) + for (f <- `match`) { + fileList += f + findFoldersInFolderRecursively(f, fileList) + } + } + } + + def findAllInFolderRecursivelyByStringContains(dir: File, fileList: ListBuffer[File], pattern: String): Unit = { + if (dir.isDirectory) { + var `match` : Array[File] = dir.listFiles(new FileFilter { + def accept(f: File): Boolean = { + return (f.isDirectory || f.getName.contains(pattern)) + } + }) + for (f <- `match`) { + fileList += f + if (f.isDirectory) { + findAllInFolderRecursivelyByStringContains(f, fileList, pattern) + } + } + } + } + + def check(expectedCount: Int): Unit = { + var dir: File = new File(randomOutputDir) + val fileList = new ListBuffer[File] + findAllInFolderRecursivelyByStringContains(dir, fileList, "clean") + assertEquals(expectedCount, fileList.size) + } +} \ No newline at end of file ----------------------------------------------------------------------- Summary of changes: .../TimeBasedRollingWithArchiveRemoval_STest.scala | 135 ++++++++++++++++++++ 1 files changed, 135 insertions(+), 0 deletions(-) create mode 100644 logback-core/src/test/scala/ch/qos/logback/core/rolling/TimeBasedRollingWithArchiveRemoval_STest.scala hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[JIRA] Created: (LBCORE-219) Date are garbage
by sanchay (JIRA) 28 Aug '11

28 Aug '11

Date are garbage ---------------- Key: LBCORE-219 URL: http://jira.qos.ch/browse/LBCORE-219 Project: logback-core Issue Type: Bug Affects Versions: 0.9.29 Environment: java version "1.6.0_17" OpenJDK Runtime Environment (IcedTea6 1.7.4) (rhel-1.21.b17.el6-x86_64) OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) Reporter: sanchay Assignee: Logback dev list Priority: Critical Sometimes I get these: [2011-17-26 23:17:20] [10461252] [main] INFO ... [2011-59-26 23:59:52] [13013252] [main] INFO ... [2011-07-27 00:07:55] [13495801] [main] INFO ... [2011-08-27 00:08:48] [13548993] [main] INFO ... [2011-09-27 00:09:36] [13597328] [main] INFO ... -- 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: (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-288) javadoc errors in class ch.qos.logback.classic.turbo.DynamicThresholdFilter.
by Bryan Lin (JIRA) 25 Aug '11

25 Aug '11

javadoc errors in class ch.qos.logback.classic.turbo.DynamicThresholdFilter. ---------------------------------------------------------------------------- Key: LBCLASSIC-288 URL: http://jira.qos.ch/browse/LBCLASSIC-288 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.29 Environment: winxp Reporter: Bryan Lin Assignee: Logback dev list There are some javadoc errors in class ch.qos.logback.classic.turbo.DynamicThresholdFilter. In the front of this class, it was some description and two configuration examples, both of them have the same type error: <DefaultTheshold>ERROR</DefaultTheshold> should be <DefaultThreshold>ERROR</DefaultThreshold> the first one miss a "r". -- 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 1

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.29-19-gb336c69
by git-noreply＠pixie.qos.ch 25 Aug '11

25 Aug '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 b336c697267f83057e708e56006f4c3322320b5c (commit) from c65a76208681877c22de7a35c44dbade67919528 (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=b336c697267f83057e708e56… http://github.com/ceki/logback/commit/b336c697267f83057e708e56006f4c3322320… commit b336c697267f83057e708e56006f4c3322320b5c Author: Ceki Gulcu <ceki(a)qos.ch> Date: Thu Aug 25 11:41:27 2011 +0200 fix typos reported in LBCLASSIC-288 diff --git a/logback-classic/src/main/java/ch/qos/logback/classic/turbo/DynamicThresholdFilter.java b/logback-classic/src/main/java/ch/qos/logback/classic/turbo/DynamicThresholdFilter.java index bde8a0c..9729d5f 100644 --- a/logback-classic/src/main/java/ch/qos/logback/classic/turbo/DynamicThresholdFilter.java +++ b/logback-classic/src/main/java/ch/qos/logback/classic/turbo/DynamicThresholdFilter.java @@ -66,7 +66,7 @@ import java.util.HashMap; * * <turboFilter class="ch.qos.logback.classic.turbo.DynamicThresholdFilter"> * <Key>userId</Key> - * <DefaultTheshold>ERROR</DefaultTheshold> + * <DefaultThreshold>ERROR</DefaultThreshold> * <MDCValueLevelPair> * <value>user1</value> * <level>DEBUG</level> @@ -102,7 +102,7 @@ import java.util.HashMap; * * <turboFilter class="ch.qos.logback.classic.turbo.DynamicThresholdFilter"> * <Key>userId</Key> - * <DefaultTheshold>ERROR</DefaultTheshold> + * <DefaultThreshold>ERROR</DefaultThreshold> * <OnHigherOrEqual>ACCEPT</OnHigherOrEqual> * <OnLower>DENY</OnLower> * <MDCValueLevelPair> ----------------------------------------------------------------------- Summary of changes: .../classic/turbo/DynamicThresholdFilter.java | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0