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

[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

[JIRA] Commented: (LBCORE-41) FixedWindowRollingPolicy MAX_WINDOW_SIZE too small?
by Patrick Crocker (JIRA) 29 Jul '11

29 Jul '11

[ http://jira.qos.ch/browse/LBCORE-41?page=com.atlassian.jira.plugin.system.i… ] Patrick Crocker commented on LBCORE-41: --------------------------------------- I too believe that logback should not be establishing arbitrary policy as to what is 'too big' for the FixedWindowRollingPolicy. I replaced commons-logging/log4j with slf4j/logback-classic on an existing project. The log4j rules were already established with a rolling policy of 100 backups. The only way I was able to complete the logback conversion was to copy the original logback FixedWindowRollingPolicy class into a new com.company.FixedLargeWindowRollingPolicy class with the MAX_WINDOW_SIZE code removed. As logback updates to the FixedWindowRollingPolicy class have come out, I've had the task of manually updating my copy with the latest updates. That has changed now that 0.9.29 changed the FixedWindowRollingPolicy class to reference a package-scoped RollingPolicy.Base.zipEntryFileNamePattern field. Since the field is package-scoped, the only way I can keep my hack current is to change my classes package to match the RollingPolicyBase package (ch.qos.logback.core.rolling). This is getting way too messy now. Can't we just have the limitation removed and leave it up to the business to decide how big a window is too big? > FixedWindowRollingPolicy MAX_WINDOW_SIZE too small? > --------------------------------------------------- > > Key: LBCORE-41 > URL: http://jira.qos.ch/browse/LBCORE-41 > Project: logback-core > Issue Type: Improvement > Components: Rolling > Affects Versions: unspecified > Environment: Operating System: Windows > Platform: All > Reporter: Mike Mansell > Assignee: Logback dev list > Priority: Minor > > I know it's not a blog but let me first say I've switched from log time use of JCL / log4j and think SLF4J / Logback is awesome so kudos to you guys for getting this out here... simple and powerful.. not much to not like ;-) > I'm curious as to why a window size as small as 12 was chosen here. I realize the renaming of all files within the window gets more expensive as the window increases but it seems prohibitive for people with larger logging requirements. Moreover, the fact that it is final means I can't override this either although I realize it is rather trivial to build my own implementation. > I have a project that generates a tremendous amount of logging currently (about 100MB every 6 minutes) and in my current setup have issues with files over 2GB. With the current MAX_WINDOW_SIZE I can only keep a days worth of logs! > If the rename is a big deal a rolling policy that just uses the index as a cyclic sequence should work fine or are there other reasons to cap this at something so low? > I could submit an implementation back if you like but just curious to get your feedback and any reasoning I might be missing on keeping the window size so low. > Thanks again for a great product! -- 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

1 0

[JIRA] Created: (LBCLASSIC-285) Tomcat integration - internal, access and webapps logging
by Sébastien (JIRA) 28 Jul '11

28 Jul '11

Tomcat integration - internal, access and webapps logging --------------------------------------------------------- Key: LBCLASSIC-285 URL: http://jira.qos.ch/browse/LBCLASSIC-285 Project: logback-classic Issue Type: Improvement Components: Other Affects Versions: 0.9.29 Reporter: Sébastien Assignee: Logback dev list I have spend several hours on the last few days to integrate SLF4J with logback in tomcat 6.0.32 ; My use case is that I want to use slf4j and logback to process all log from tomcat, associated libraries, logback-access and several webapps, each of those webapps having their own configuration file. I came to logback hoping to have a better experience than with log4j regarding (advertised) context separation and co, but it have been quite more painful than expected. I have used the solution posted here https://github.com/grgrzybek/tomcat-slf4j-logback which is very useful (thanks!) but still suffer from multiple inconveniences. - It's a bit of a hack ; a very nicely packaged one, but still, having to relocate the package to another namespace and having two copies of the framework is not a smooth integration. - if you want both tomcat internal -> slf4j -> logback and logback-access, you end up with copies of logback-core and logback-classic in lib/ and suffer from context leakage between webapps which target the common jar - if you tries to circumvent the former problem with the use of the context JNDI selector, it is picked also by the package relocated tomcat-logback used for internal tomcat logging and go to a bootstrap issue with naming services since it is called early in tomcat start sequence. One could try to patch more the relocated package to rename the property name used to set context selector, but it is adding more complexity and renaming to the relocation hack - I ended up adding logback-access to the package relocation build and use the renamed version ; it works but hardly elegant and still does not solve other problems. - If your have an endorsed/ dir in tomcat with some libraries, coming say from apache foundation, that use commons logging, the jcl-slf4j bridge works well but you end up with slf4j and logback in endorsed/ and you also say good by to free context isolation by webapp classloader and copies of logback in each webapp. - to be sure to choose the good logback configuration for a webapp, I used the ServletContextListener from LBCLASSIC-202 ; a good solution but requires more packaging since it's not present in standard distribution. I think it could work better with the availability of a bit more Context selector logic, but before digging further, i'm interested to know if there is some work going on in those areas, which I would prefer not to duplicate. -- 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

1 0

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.29-16-g707298f
by git-noreply＠pixie.qos.ch 21 Jul '11

21 Jul '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 707298f12c4d6a5ae392a0c2c5bb488cbcc4f8ef (commit) from 6058b4beb2019cc7f6be39312ee9ad2fbd88db6c (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=707298f12c4d6a5ae392a0c2… http://github.com/ceki/logback/commit/707298f12c4d6a5ae392a0c2c5bb488cbcc4f… commit 707298f12c4d6a5ae392a0c2c5bb488cbcc4f8ef Author: Ceki Gulcu <ceki(a)qos.ch> Date: Thu Jul 21 11:30:35 2011 +0200 added a link to the logback-akka project diff --git a/logback-site/src/site/pages/download.html b/logback-site/src/site/pages/download.html index 634a00d..d7314e3 100644 --- a/logback-site/src/site/pages/download.html +++ b/logback-site/src/site/pages/download.html @@ -52,8 +52,8 @@ </p> <ul> - <li><a href="dist/logback-${pom.version}.zip">logback-${pom.version}.zip</a></li> - <li><a href="dist/logback-${project.version}.tar.gz">logback-${pom.version}.tar.gz</a></li> + <li><a href="dist/logback-${project.version}.zip">logback-${project.version}.zip</a></li> + <li><a href="dist/logback-${project.version}.tar.gz">logback-${project.version}.tar.gz</a></li> </ul> @@ -63,12 +63,13 @@ <p>A console plugin for Eclipse is also available. It allows you - to receive logging events in a convenient Eclipse view, and - offers integration with logback's filtering - framework, among other features. A more precise description can be found in the plugin's + to receive logging events in a convenient Eclipse view, and offers + integration with logback's filtering framework, among other + features. A more precise description can be found in the plugin's <a href="consolePlugin.html">user guide</a>. <b>Unfortunately, the - console plugin is somewhat outdated. It expects logback version - 0.9.9. It will be upgraded in the coming weeks.</b></p> + console plugin is very much outdated. It expects logback version + 0.9.9. It will be upgraded during the second semester of + 2011.</b></p> <ul> @@ -81,7 +82,12 @@ <hr/> - <h2>Third-party tools</h2> + <h2>Third-party tools, extensions or forks</h2> + + <p>If you are the author of a logback-related project and would + like us to add your project to the list below please drop a line + on the logback-dev mailing list.</p> + <dl> <dt> @@ -95,28 +101,33 @@ classic.</p> </dd> - +  <dt> <a href="http://lilith.huxhorn.de">Lilith</a> by Joern Huxhorn </dt> <dd> - <p>Lilith is a Logging- and AccessEvent viewer for logback. - </p> + <p>Lilith is a Logging- and AccessEvent viewer for logback.</p> </dd> - </dl> +  + <dt> + <a + href="https://github.com/mojolly/logback-akka">Logback-akka</a> + by Ivan Porto Carrero. + </dt> - - <hr/> + <dd> + <p>Consists of several akka-based logback utilities, including + ActorAppender, HoptoadActorAppender and Logstash redis + appender. + </p> + </dd> - <h2>Forks</h2> + + </dl> - <p>At present time there are 18 forks of logback on github. If you - are the author of one of these forks and would like feedback from - potential users, please drop us a line at the logback-dev mailing list - with a brief description of your fork. We will gladly add a link to - your fork to the list below (currently empty).</p> + <p/> ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/download.html | 51 +++++++++++++++++----------- 1 files changed, 31 insertions(+), 20 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.29-15-g6058b4b
by git-noreply＠pixie.qos.ch 21 Jul '11

21 Jul '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 6058b4beb2019cc7f6be39312ee9ad2fbd88db6c (commit) from 65ba3dd0024c9145f7ade9b520f722a0e7324ff4 (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=6058b4beb2019cc7f6be3931… http://github.com/ceki/logback/commit/6058b4beb2019cc7f6be39312ee9ad2fbd88d… commit 6058b4beb2019cc7f6be39312ee9ad2fbd88db6c Author: Ceki Gulcu <ceki(a)qos.ch> Date: Thu Jul 21 10:57:23 2011 +0200 typo fixes diff --git a/logback-classic/src/main/java/ch/qos/logback/classic/jmx/JMXConfigurator.java b/logback-classic/src/main/java/ch/qos/logback/classic/jmx/JMXConfigurator.java index f3d947f..0aa88ca 100644 --- a/logback-classic/src/main/java/ch/qos/logback/classic/jmx/JMXConfigurator.java +++ b/logback-classic/src/main/java/ch/qos/logback/classic/jmx/JMXConfigurator.java @@ -270,7 +270,7 @@ public class JMXConfigurator extends ContextAwareBase implements } /** - * JMXConfigrator should not be removed subsequent to a LoggerContext reset. + * JMXConfigurator should not be removed subsequent to a LoggerContext reset. * * @return */ diff --git a/logback-site/src/site/pages/manual/groovy.html b/logback-site/src/site/pages/manual/groovy.html index a3443c6..2f419ed 100644 --- a/logback-site/src/site/pages/manual/groovy.html +++ b/logback-site/src/site/pages/manual/groovy.html @@ -114,7 +114,7 @@ root(WARN)</pre> - <p>To set the level of the root logger to DEBUG, and attach + <p>To set the level of the root logger to INFO, and attach appenders named "CONSOLE" and "FILE" to root, you would write:</p> <pre class="prettyprint source">import static ch.qos.logback.classic.Level.INFO ----------------------------------------------------------------------- Summary of changes: .../qos/logback/classic/jmx/JMXConfigurator.java | 2 +- logback-site/src/site/pages/manual/groovy.html | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0