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

[JIRA] Created: (LBCORE-147) RollingPolicy MaxHistory not deleting old files
by Rafael Diaz Maurin (JIRA) 04 Oct '11

04 Oct '11

RollingPolicy MaxHistory not deleting old files ----------------------------------------------- Key: LBCORE-147 URL: http://jira.qos.ch/browse/LBCORE-147 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.18 Environment: linux 2.6.18 64bits apache-tomcat-6.0.20 java/jre1.6.0_18 Reporter: Rafael Diaz Maurin Assignee: Logback dev list The MaxHistory does not do the trick : the old files are not deleted at all : cat logging.xml <appender name="IDP_ACCESS" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>/shibboleth-idp/logs/idp-access.log</File> <Append>false</Append> <ImmediateFlush>true</ImmediateFlush> <RollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>/shibboleth-idp/logs/old/idp-access-%d{yyyy-MM-dd_HH-mm}.log.gz</FileNamePattern> <MaxHistory>3</MaxHistory> </RollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%msg%n</Pattern> </layout> </appender> -- 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

11 35

[JIRA] Created: (LBCLASSIC-283) SerializationPerfTest crashes due to LoggingEvent being not serializable
by Pierre Queinnec (JIRA) 04 Oct '11

04 Oct '11

SerializationPerfTest crashes due to LoggingEvent being not serializable ------------------------------------------------------------------------ Key: LBCLASSIC-283 URL: http://jira.qos.ch/browse/LBCLASSIC-283 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.30 Reporter: Pierre Queinnec Assignee: Logback dev list SerializationPerfTest crashes due to LoggingEvent being not serializable. This can be trivially fixed using LoggingEventVO. I'll open a pull request with the changes, as I was interested in the benchmark. 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

2 2

[JIRA] Created: (LBACCESS-25) Infinite loops in AccessConverter#addError
by Pierre Queinnec (JIRA) 30 Sep '11

30 Sep '11

Infinite loops in AccessConverter#addError ------------------------------------------ Key: LBACCESS-25 URL: http://jira.qos.ch/browse/LBACCESS-25 Project: logback-access Issue Type: Bug Affects Versions: 0.9.30 Reporter: Pierre Queinnec Assignee: Logback dev list The addError(String msg) and addError(String msg, Throwable ex) methods seem to be calling themselves in an infinite loop. I'll open a pull-request. -- 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: (LBACCESS-17) LogbackValve overrides final start() method from LifecycleBase in Tomcat 7
by Grzegorz Grzybek (JIRA) 30 Sep '11

30 Sep '11

LogbackValve overrides final start() method from LifecycleBase in Tomcat 7 -------------------------------------------------------------------------- Key: LBACCESS-17 URL: http://jira.qos.ch/browse/LBACCESS-17 Project: logback-access Issue Type: Bug Affects Versions: 0.9.26 Reporter: Grzegorz Grzybek Assignee: Logback dev list Priority: Critical {code} java.lang.VerifyError: class ch.qos.logback.access.tomcat.LogbackValve overrides final method start.()V {code} Tomcat 7 has changed the LifecycleBase implementation - it should not override start() but rather startInternal() -- 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 3

[JIRA] Created: (LBCLASSIC-217) Exception stack trace printing starting from root cause
by Tomasz Nurkiewicz (JIRA) 24 Sep '11

24 Sep '11

Exception stack trace printing starting from root cause ------------------------------------------------------- Key: LBCLASSIC-217 URL: http://jira.qos.ch/browse/LBCLASSIC-217 Project: logback-classic Issue Type: New Feature Affects Versions: 0.9.22 Reporter: Tomasz Nurkiewicz Assignee: Logback dev list A typical exception in multi-tier application looks similar to this: com.acme.BusinessException: Can't process request at ... at ... Caused by: com.acme.dao.PersistenceException: Can't access database at ... at ... ... 49 common frames omitted Caused by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to locate datasource at ... at ... ... 65 common frames omitted Caused by: java.net.UnknownHostException: Unknown host localhostt at ... at ... ... 84 common frames omitted The deeper exception, the more specific information it gives. Typically the last "Caused by" is the most interesting one. So it seems like reversing the order in which the exceptions are thrown (from most specific to consecutive, less specific wrappers) might be more intuitive: java.net.UnknownHostException: Unknown host localhostt at ... at ... Wrapped by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to connect to the database at ... at ... Wrapped by: com.acme.dao.PersistenceException: Can't access database at ... at ... Wrapped by: com.acme.BusinessException: Can't process request at ... at ... It is not only easier to read and follow (business exception is interesting for the end user while the most precise, technical information is for developers and system administrators - so it should be easily accessible in the logs), but also the stack trace isn't mixed. You can read stack frames in exactly the same order as they were executed, no need to jump from one stack trace line to another (see attachment from the real application). This also means that the beginning of the thread is always at the bottom and the line that caused the very first exception - at the top. (look at the attached real exception) I already implemented this feature by adding RootCauseFirstThrowableProxyConverter extending ch.qos.logback.classic.pattern.ExtendedThrowableProxyConverter. It is turned on by appending "%rEx" to the encoder pattern. If you like this feature, I will push the changes (just few classes have changed) into my GitHub fork. -- 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: (LBCLASSIC-273) Status messages of StatusManager are not cleared upon call to LoggerContext.reset()
by Joern Huxhorn (JIRA) 22 Sep '11

22 Sep '11

Status messages of StatusManager are not cleared upon call to LoggerContext.reset() ----------------------------------------------------------------------------------- Key: LBCLASSIC-273 URL: http://jira.qos.ch/browse/LBCLASSIC-273 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.28 Reporter: Joern Huxhorn Assignee: Logback dev list See https://github.com/ceki/logback/pull/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

2 8

[JIRA] Created: (LBCLASSIC-267) Intermittent ConcurrentModificationException in LoggingEvent.prepareForDeferredProcessing
by Anders Wallgren (JIRA) 20 Sep '11

20 Sep '11

Intermittent ConcurrentModificationException in LoggingEvent.prepareForDeferredProcessing ----------------------------------------------------------------------------------------- Key: LBCLASSIC-267 URL: http://jira.qos.ch/browse/LBCLASSIC-267 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.28 Reporter: Anders Wallgren Assignee: Logback dev list Occasionally seeing this type of exception: 02:02:27,883 |-ERROR in com.electriccloud.log.AsyncAppender[ASYNC_FILE] - Appender [ASYNC_FILE] failed to append. java.util.ConcurrentModificationExceptionjava.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) at java.util.HashMap$EntryIterator.next(HashMap.java:834) at java.util.HashMap$EntryIterator.next(HashMap.java:832) at java.util.HashMap.putAllForCreate(HashMap.java:435) at java.util.HashMap.<init>(HashMap.java:225) at ch.qos.logback.classic.spi.LoggingEvent.prepareForDeferredProcessing(LoggingEvent.java:213) at com.electriccloud.log.AsyncAppender.append(AsyncAppender.java:132) at com.electriccloud.log.AsyncAppender.append(AsyncAppender.java:36) at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:85) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:64) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:285) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:272) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:473) at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:427) at ch.qos.logback.classic.Logger.debug(Logger.java:534) at com.electriccloud.log.Slf4jLog.debug(Slf4jLog.java:66) at com.electriccloud.log.Slf4jLog.log(Slf4jLog.java:202) at com.electriccloud.util.timer.Timer.logElapsed(Timer.java:324) at com.electriccloud.operations.OperationTimingAspect.logOperationPerformance(OperationTimingAspect.java:107) at sun.reflect.GeneratedMethodAccessor124.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:627) at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:616) at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:64) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:160) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy23.perform(Unknown Source) at com.electriccloud.operations.OperationInvoker.invoke(OperationInvoker.java:273) at com.electriccloud.operations.OperationCaller.call(OperationCaller.java:127) at com.electriccloud.operations.OperationCaller.call(OperationCaller.java:42) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) at com.electriccloud.util.CommanderThread.run(CommanderThread.java:105) -- 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-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