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

Question about a custom binary file appender.
by Joern Huxhorn 02 Aug '09

02 Aug '09

Hi Ceki. I'd like to implement a file appender that writes the binary Lilith format, i.e. gzipped protobuf-serialized events, instead of Strings. I'd also like to have the same functionality that's supported by RollingFileAppender right now. Unfortunately, there seems to be no way to simply write bytes instead of a String. How would you go from here? Reimplementing everything from the start seems to be a pretty bad idea. What do you think about enhancing the RFA so it's using byte[] instead of Strings? The current behavior could be implemented using those methods + string.getBytes("UTF-8") or CharsetEncoder... Any idea, suggestions? Regards, Joern.

3 8

[JIRA] Created: (LBCLASSIC-114) add a context listener that automatically configures JMX
by Philippe Marschall (JIRA) 31 Jul '09

31 Jul '09

add a context listener that automatically configures JMX -------------------------------------------------------- Key: LBCLASSIC-114 URL: http://jira.qos.ch/browse/LBCLASSIC-114 Project: logback-classic Issue Type: New Feature Components: Other Reporter: Philippe Marschall Assignee: Logback dev list Priority: Minor Setting up logback JMX for a web application requires a bit too many manual steps. It is not enough to simply add <jmxConfigurator /> to the configuration file. You should also set the context path but often you can't know that in advance. In addition you still need to write custom code to [prevent memory leaks|http://logback.qos.ch/manual/jmxConfig.html#leak]. These issues could all be addressed by a custom context listener. <listener> <listener-class>ch.qos.logback.classic.selector.servlet.JmxEnabler</listener-class> </listener> Code attached. -- 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 4

[JIRA] Created: (LBCLASSIC-125) NoClassDefFoundError in PackagingDataCalculator.loadClass()
by Roland Klein (JIRA) 22 Jul '09

22 Jul '09

NoClassDefFoundError in PackagingDataCalculator.loadClass() ----------------------------------------------------------- Key: LBCLASSIC-125 URL: http://jira.qos.ch/browse/LBCLASSIC-125 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.15 Environment: jdk 1.6 (build 1.6.0_10-b33) jboss 4.2.2ga Reporter: Roland Klein Assignee: Logback dev list In an EJB Client/Server Environment the loadClass() method could fail, because the vm issues a NoClassDefFoundError. And there is no corresponding catch, so the whole logging fails and throws a NoClassDefFoundError. -- 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 10

[JIRA] Created: (LBCLASSIC-109) Logger allows TRACE messages when reset to DEBUG
by Andrew Ruch (JIRA) 21 Jul '09

21 Jul '09

Logger allows TRACE messages when reset to DEBUG ------------------------------------------------ Key: LBCLASSIC-109 URL: http://jira.qos.ch/browse/LBCLASSIC-109 Project: logback-classic Issue Type: Bug Environment: SLF4J 1.5.6 and Logback 0.9.15 Reporter: Andrew Ruch Assignee: Logback dev list Priority: Minor When reconfiguring the LoggerContext, TRACE messages are logged even when the Logger level is set to DEBUG. As Ceki pointed out, the following test reproduces the issue. @Test public void levelResetTest() { LoggerContext loggerContext = new LoggerContext(); Logger root = loggerContext.getLogger(LoggerContext.ROOT_NAME); root.setLevel(Level.TRACE); assertTrue(root.isTraceEnabled()); loggerContext.reset(); //Logger is reset to DEBUG assertFalse(root.isTraceEnabled()); <-- assertion fails assertTrue(root.isDebugEnabled()); } -- 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: (LBCORE-59) Support for reconfiguration at runtime
by Michael Osipov (JIRA) 20 Jul '09

20 Jul '09

Support for reconfiguration at runtime -------------------------------------- Key: LBCORE-59 URL: http://jira.qos.ch/browse/LBCORE-59 Project: logback-core Issue Type: New Feature Components: Joran Affects Versions: 0.9.9 Reporter: Michael Osipov Assignee: Logback dev list Joran should support reconfiguration at runime like log4j's DOMConfigurator#configureAndWatch. -- 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 8

[JIRA] Created: (LBCLASSIC-134) DuplicateMessageFilter should bypass checking msgCache for null formats
by Darryl Smith (JIRA) 08 Jul '09

08 Jul '09

DuplicateMessageFilter should bypass checking msgCache for null formats ----------------------------------------------------------------------- Key: LBCLASSIC-134 URL: http://jira.qos.ch/browse/LBCLASSIC-134 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.15 Reporter: Darryl Smith Assignee: Logback dev list Attachments: LBCLASSIC-134.patch Calls to isXXXEnabled translate to a call to Logger.callTurboFilters which invokes DuplicateMessageFilter with a null format DuplicateMessageFilter usage of LRUMessageCache will group together all null formats under msgCount. e.g. msgCache.getMessageCount(null) = msgCount 1 msgCache.getMessageCount(null) = msgCount 2 msgCache.getMessageCount(null) = msgCount 3 -- 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-94) Rollover at launch time
by Ceki Gulcu (JIRA) 08 Jul '09

08 Jul '09

Rollover at launch time ----------------------- Key: LBCORE-94 URL: http://jira.qos.ch/browse/LBCORE-94 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.15 Reporter: Ceki Gulcu Assignee: Ceki Gulcu Rollover does not occur for old files when short lived application is restarted. This issue is related to LBCORE-26.However, the solution implemented in LBCORE-26 works if the RollingFileAppender has the File property set. This is not always the case. For instance <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>test.%d.log.zip</FileNamePattern> </rollingPolicy> <layout/> </appender> <root level="info"> <appender-ref ref="FILE"/> </root> Problem originally reported by Ch Pasha. See also http://www.qos.ch/pipermail/logback-user/2009-March/001030.html -- 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 4

[JIRA] Created: (LBCORE-60) Allow rolling based on time or file size
by Szel Zoltan (JIRA) 02 Jul '09

02 Jul '09

Allow rolling based on time or file size ---------------------------------------- Key: LBCORE-60 URL: http://jira.qos.ch/browse/LBCORE-60 Project: logback-core Issue Type: New Feature Components: Appender Affects Versions: 0.9.9 Reporter: Szel Zoltan Assignee: Logback dev list The rolling grouping file appender allows to roll over on a specific interval(TimeBasedRollingPolicy) or when the log file has reached a specific file size. But unfortunately Logback does not support both to use together. For example if i want to roll over every day but i also want to roll the file when it is greater than 100MB. Please consider adding this feature to Logback and feel free to contact me if further clarification is required. Thanks, 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

4 9

[JIRA] Created: (LBCORE-99) Deadlock in consoleappender using logback in jetty
by Sakib Mehasanewala (JIRA) 01 Jul '09

01 Jul '09

Deadlock in consoleappender using logback in jetty -------------------------------------------------- Key: LBCORE-99 URL: http://jira.qos.ch/browse/LBCORE-99 Project: logback-core Issue Type: Bug Components: Appender Affects Versions: 0.9.15 Environment: Maven 2.1.0 jetty plugin on ubuntu linux. maven dependencies list ... <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-ext</artifactId> <version>1.5.8</version> <type>jar</type> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>jcl-over-slf4j</artifactId> <version>1.5.8</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> <version>0.9.15</version> <type>jar</type> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>0.9.15</version> <type>jar</type> </dependency> <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> <version>99.0-does-not-exist</version> </dependency Reporter: Sakib Mehasanewala Assignee: Logback dev list I came across this deadlock while running jetty via plugin in maven to run functional tests... Found one Java-level deadlock: ============================= "Shutdown": waiting to lock monitor 0xb52073c0 (object 0x7395a770, a ch.qos.logback.core.ConsoleAppender), which is held by "32900144@qtp0-0 - /cbs2/v1.0/ws/cbs2.wsdl" "32900144@qtp0-0 - /cbs2/v1.0/ws/cbs2.wsdl": waiting to lock monitor 0xb5209bfc (object 0x7391a760, a org.mortbay.jetty.webapp.WebAppClassLoader), which is held by "15510444@qtp0-2 - /cbs2/v1.0/ws/cbs2.wsdl" "15510444@qtp0-2 - /cbs2/v1.0/ws/cbs2.wsdl": waiting to lock monitor 0xb52073c0 (object 0x7395a770, a ch.qos.logback.core.ConsoleAppender), which is held by "32900144@qtp0-0 - /cbs2/v1.0/ws/cbs2.wsdl" Java stack information for the threads listed above: =================================================== "Shutdown": at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:66) - waiting to lock <0x7395a770> (a ch.qos.logback.core.ConsoleAppender) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:60) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:439) at ch.qos.logback.classic.Logger.filterAndLog_2(Logger.java:430) at ch.qos.logback.classic.Logger.info(Logger.java:605) 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.mortbay.log.Slf4jLog.info(Slf4jLog.java:103) at org.mortbay.log.Log.info(Log.java:132) at org.mortbay.jetty.Server$ShutdownHookThread.run(Server.java:550) "32900144@qtp0-0 - /cbs2/v1.0/ws/cbs2.wsdl": at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:341) - waiting to lock <0x7391a760> (a org.mortbay.jetty.webapp.WebAppClassLoader) at ch.qos.logback.classic.spi.PackagingDataCalculator.loadClass(PackagingDataCalculator.java:232) at ch.qos.logback.classic.spi.PackagingDataCalculator.bestEffortLoadClass(PackagingDataCalculator.java:257) at ch.qos.logback.classic.spi.PackagingDataCalculator.computeBySTEP(PackagingDataCalculator.java:166) at ch.qos.logback.classic.spi.PackagingDataCalculator.populateFrames(PackagingDataCalculator.java:97) at ch.qos.logback.classic.spi.PackagingDataCalculator.calculate(PackagingDataCalculator.java:61) at ch.qos.logback.classic.spi.ThrowableProxy.calculatePackagingData(ThrowableProxy.java:50) at ch.qos.logback.classic.pattern.ExtendedThrowableProxyConverter.prepareLoggingEvent(ExtendedThrowableProxyConverter.java:35) at ch.qos.logback.classic.pattern.ThrowableProxyConverter.convert(ThrowableProxyConverter.java:142) at ch.qos.logback.classic.pattern.ThrowableProxyConverter.convert(ThrowableProxyConverter.java:30) at ch.qos.logback.core.pattern.FormattingConverter.write(FormattingConverter.java:32) at ch.qos.logback.core.pattern.PatternLayoutBase.writeLoopOnConverters(PatternLayoutBase.java:110) at ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:132) at ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:51) at ch.qos.logback.core.WriterAppender.subAppend(WriterAppender.java:261) at ch.qos.logback.core.WriterAppender.append(WriterAppender.java:114) at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:87) - locked <0x7395a770> (a ch.qos.logback.core.ConsoleAppender) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:60) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:439) at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:393) at ch.qos.logback.classic.Logger.warn(Logger.java:710) 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.mortbay.log.Slf4jLog.warn(Slf4jLog.java:128) at org.mortbay.log.Log.warn(Log.java:181) at org.mortbay.log.Log.unwind(Log.java:216) at org.mortbay.log.Log.warn(Log.java:182) at org.mortbay.log.Log.unwind(Log.java:216) at org.mortbay.log.Log.warn(Log.java:182) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:414) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:320) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:864) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:533) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:207) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:403) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:522) "15510444@qtp0-2 - /cbs2/v1.0/ws/cbs2.wsdl": at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:66) - waiting to lock <0x7395a770> (a ch.qos.logback.core.ConsoleAppender) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:60) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:439) at ch.qos.logback.classic.Logger.filterAndLog_2(Logger.java:430) at ch.qos.logback.classic.Logger.debug(Logger.java:508) at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.mortbay.log.Slf4jLog.debug(Slf4jLog.java:73) at org.mortbay.log.Log.debug(Log.java:90) at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:388) - locked <0x7391a760> (a org.mortbay.jetty.webapp.WebAppClassLoader) at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:341) - locked <0x7391a760> (a org.mortbay.jetty.webapp.WebAppClassLoader) at com.sun.org.apache.xerces.internal.parsers.ObjectFactory.findProviderClass(ObjectFactory.java:393) at com.sun.org.apache.xerces.internal.parsers.ObjectFactory.newInstance(ObjectFactory.java:348) at com.sun.org.apache.xerces.internal.parsers.ObjectFactory.createObject(ObjectFactory.java:154) at com.sun.org.apache.xerces.internal.parsers.ObjectFactory.createObject(ObjectFactory.java:97) at com.sun.org.apache.xerces.internal.parsers.DOMParser.<init>(DOMParser.java:125) at com.sun.org.apache.xerces.internal.parsers.DOMParser.<init>(DOMParser.java:109) at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.<init>(DocumentBuilderImpl.java:115) at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(DocumentBuilderFactoryImpl.java:72) at com.sun.org.apache.xalan.internal.xsltc.trax.SAX2DOM.<init>(SAX2DOM.java:69) - locked <0x912b1278> (a java.lang.Class for com.sun.org.apache.xalan.internal.xsltc.trax.SAX2DOM) at com.sun.org.apache.xalan.internal.xsltc.runtime.output.TransletOutputHandlerFactory.getSerializationHandler(TransletOutputHandlerFactory.java:187) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getOutputHandler(TransformerImpl.java:392) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:298) at org.springframework.ws.transport.http.WsdlDefinitionHandlerAdapter.handle(WsdlDefinitionHandlerAdapter.java:125) at org.springframework.ws.transport.http.MessageDispatcherServlet.doService(MessageDispatcherServlet.java:222) at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:613) at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:525) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1124) at com.diginsite.services.cbs2.filter.ClearRequestContextFilter.doFilter(ClearRequestContextFilter.java:34) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:361) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:320) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:864) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:533) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:207) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:403) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:522) Found 1 deadlock. Heap def new generation total 3904K, used 115K [0x70060000, 0x70490000, 0x727c0000) eden space 3520K, 3% used [0x70060000, 0x7007cda8, 0x703d0000) from space 384K, 0% used [0x703d0000, 0x703d0000, 0x70430000) to space 384K, 0% used [0x70430000, 0x70430000, 0x70490000) tenured generation total 50668K, used 26395K [0x727c0000, 0x7593b000, 0x90060000) the space 50668K, 52% used [0x727c0000, 0x74186f40, 0x74187000, 0x7593b000) compacting perm gen total 20736K, used 20517K [0x90060000, 0x914a0000, 0x94060000) the space 20736K, 98% used [0x90060000, 0x914697a0, 0x91469800, 0x914a0000) ro space 8192K, 74% used [0x94060000, 0x94658b48, 0x94658c00, 0x94860000) rw space 12288K, 58% used [0x94860000, 0x94f73df0, 0x94f73e00, 0x95460000) -- 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 14

[JIRA] Created: (LBGENERAL-29) Revision 2296 does not build executing "mvn clean install"
by Joern Huxhorn (JIRA) 01 Jul '09

01 Jul '09

Revision 2296 does not build executing "mvn clean install" ---------------------------------------------------------- Key: LBGENERAL-29 URL: http://jira.qos.ch/browse/LBGENERAL-29 Project: logback-general Issue Type: Bug Environment: Maven version: 2.0.10 Java version: 1.6.0_13 OS name: "mac os x" version: "10.5.7" arch: "x86_64" Family: "mac" Reporter: Joern Huxhorn Assignee: Logback dev list Lots of strange errors are reported by Maven. I suspect that it's a bug in the surefire-plugin as all internal classes of tests are interpreted as test-classes... Anyway, I've fixed this. Patch is upcoming. -- 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