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

[JIRA] Created: (LBCORE-146) SiftingAppender TimeBasedRollingPolicy MaxHistory not deleting old files
by Hrotkó Gábor (JIRA) 03 Feb '12

03 Feb '12

SiftingAppender TimeBasedRollingPolicy MaxHistory not deleting old files ------------------------------------------------------------------------ Key: LBCORE-146 URL: http://jira.qos.ch/browse/LBCORE-146 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.18 Environment: linux64, jdk1.6.0_17-b04, apache-tomcat-6.0.24 Reporter: Hrotkó Gábor Assignee: Logback dev list When I use SiftingAppender with TimeBasedRollingPolicy, old files does not get deleted when the MaxHistory is set. logback.xml snipet: <configuration debug="true" scan="true" scanPeriod="5 seconds"> <appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator> <Key>userid</Key> <DefaultValue>base</DefaultValue> </discriminator> <sift> <appender name="FILE-${userid}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>/usr/local/tomcat6/logs/myLog_${userid}.log</File> <Append>false</Append> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %level %mdc %logger.%method:%line - %msg%n</Pattern> </layout> <RollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>/usr/local/tomcat6/logs/myLog_${userid}.%d{yyyy-MM-dd}.log</FileNamePattern>  <MaxHistory>2</MaxHistory> </RollingPolicy> </appender> </sift> </appender> ... With the config above, the files gets sifted and rolled well, but old files not deleted. When I change the filenames, and delete the ${userid} sifting, it works well. ... <File>/usr/local/tomcat6/logs/myLog.log</File> ... <FileNamePattern>/usr/local/tomcat6/logs/myLog.%d{yyyy-MM-dd}.log</FileNamePattern> ... -- 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 1

[JIRA] Created: (LBCLASSIC-261) MongoDB appender
by Tomasz Nurkiewicz (JIRA) 15 Nov '11

15 Nov '11

MongoDB appender ---------------- Key: LBCLASSIC-261 URL: http://jira.qos.ch/browse/LBCLASSIC-261 Project: logback-classic Issue Type: New Feature Components: appender Affects Versions: 0.9.28 Reporter: Tomasz Nurkiewicz Assignee: Logback dev list An appender similar to DbAppender, but storing logs in MongoDB document-oriented database. Should be capable of storing both classic and access logs. MongoDB seems especially well suited for this task since it is schema-less and very fast. Prototype implementation + integration tests (MongoDB instance running required) can be found here: https://github.com/nurkiewicz/logback/tree/mongodb-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

2 1

[JIRA] Created: (LBCLASSIC-171) Exception data sometimes does not get logged when using warn(String, Throwable)
by Marshall Pierce (JIRA) 25 Oct '11

25 Oct '11

Exception data sometimes does not get logged when using warn(String, Throwable) ------------------------------------------------------------------------------- Key: LBCLASSIC-171 URL: http://jira.qos.ch/browse/LBCLASSIC-171 Project: logback-classic Issue Type: Bug Affects Versions: 0.917 Environment: Linux, sun jdk 1.6.0_07 Reporter: Marshall Pierce Assignee: Logback dev list Source: try { doStuff(); } catch (PhaseException e) { this.logger.warn("Phase failed:", e); this.logger.debug("Another log message"); ... Log contents: phase.StandardPhase - Phase failed: phase.StandardPhase - Another log message The strange thing is that this doesn't happen all the time or even most of the time. Almost always, the exception data does get logged. -- 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-131) Missing Import-Package declaration in logback-classic causes problem with RollingFileAppender
by Pavol Juhos (JIRA) 25 Oct '11

25 Oct '11

Missing Import-Package declaration in logback-classic causes problem with RollingFileAppender --------------------------------------------------------------------------------------------- Key: LBCLASSIC-131 URL: http://jira.qos.ch/browse/LBCLASSIC-131 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.15 Environment: OSGi Service Platform Release 4 Reporter: Pavol Juhos Assignee: Logback dev list In OSGi environment logback-core will correctly try to use the class-loader of logback-classic bundle to load classes of the selected Appenders. This however means that logback-classic needs to have visibility to the requested Appender classes. Since RollingFileAppender is located in a separate package "ch.qos.logback.core.rolling" and not explicitly referenced from logback-classic code, the respective Import-Package declaration will not be generated automatically by the BND tool (embedded in maven-bundle-plugin). In order to avoid ClassNotFound exceptions when trying to use RollingFileAppender the appropriate Import-Package declarations have to be added explicitly to the configuration of maven-bundle-plugin in logback-classic POM. The current <Import-Package> settings in maven-bundle-plugin configuration: <Import-Package>sun.reflect;resolution:=optional, javax.jms;resolution:=optional, * </Import-Package> Suggested update: <Import-Package>sun.reflect;resolution:=optional, javax.jms;resolution:=optional, ch.qos.logback.core.rolling, ch.qos.logback.core.rolling.helper, * </Import-Package> Please consider also to implement the related issue LBCLASSIC-121 when fixing this defect. -- 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-278) Give access to environment variables in configuration file
by Alexandre Garnier (JIRA) 17 Oct '11

17 Oct '11

Give access to environment variables in configuration file ---------------------------------------------------------- Key: LBCLASSIC-278 URL: http://jira.qos.ch/browse/LBCLASSIC-278 Project: logback-classic Issue Type: New Feature Reporter: Alexandre Garnier Assignee: Logback dev list It would be very nice to be able to access environment variables in configuration files. Maybe like in ant with <property environment="env"/> and then ${env.PATH} to access variable. In my use case, it's necessary to get the path to the property file to load... -- 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-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: (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