- logback-dev - mailman3.qos.ch

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.28-38-g79989e0
by git-noreply＠pixie.qos.ch 25 May '11

25 May '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 79989e013e314dd815b23a12fea8bcd5e16fcc49 (commit) from e4aa27eb1dae6b6278ab139444d769edf1280411 (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=79989e013e314dd815b23a12… http://github.com/ceki/logback/commit/79989e013e314dd815b23a12fea8bcd5e16fc… commit 79989e013e314dd815b23a12fea8bcd5e16fcc49 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Wed May 25 16:23:38 2011 +0200 Fixed LBCORE-199 by adding a timestamp to the entry found in the zip file. This was suggested by Benoit Xhenseval. diff --git a/logback-core/src/main/java/ch/qos/logback/core/rolling/FixedWindowRollingPolicy.java b/logback-core/src/main/java/ch/qos/logback/core/rolling/FixedWindowRollingPolicy.java index 7cb9a09..5057942 100644 --- a/logback-core/src/main/java/ch/qos/logback/core/rolling/FixedWindowRollingPolicy.java +++ b/logback-core/src/main/java/ch/qos/logback/core/rolling/FixedWindowRollingPolicy.java @@ -37,6 +37,8 @@ public class FixedWindowRollingPolicy extends RollingPolicyBase { RenameUtil util = new RenameUtil(); Compressor compressor; + public static String ZIP_ENTRY_DATE_PATTERN = "yyyy-MM-dd_HHmm"; + /** * It's almost always a bad idea to have a large window size, say over 12. */ @@ -104,7 +106,7 @@ public class FixedWindowRollingPolicy extends RollingPolicyBase { private String transformFileNamePatternFromInt2Date(String fileNamePatternStr) { String slashified = FileFilterUtil.slashify(fileNamePatternStr); String stemOfFileNamePattern = FileFilterUtil.afterLastSlash(slashified); - return stemOfFileNamePattern.replace("%i", "%d"); + return stemOfFileNamePattern.replace("%i", "%d{"+ZIP_ENTRY_DATE_PATTERN+"}"); } public void rollover() throws RolloverFailure { diff --git a/logback-core/src/test/java/ch/qos/logback/core/rolling/SizeBasedRollingTest.java b/logback-core/src/test/java/ch/qos/logback/core/rolling/SizeBasedRollingTest.java index 4e76249..36b5cd0 100644 --- a/logback-core/src/test/java/ch/qos/logback/core/rolling/SizeBasedRollingTest.java +++ b/logback-core/src/test/java/ch/qos/logback/core/rolling/SizeBasedRollingTest.java @@ -13,11 +13,16 @@ */ package ch.qos.logback.core.rolling; +import static org.junit.Assert.assertTrue; import static org.junit.Assert.fail; import java.io.File; +import java.io.IOException; import java.text.SimpleDateFormat; +import java.util.Enumeration; import java.util.List; +import java.util.zip.ZipEntry; +import java.util.zip.ZipFile; import org.junit.After; import org.junit.Before; @@ -30,12 +35,10 @@ import ch.qos.logback.core.encoder.EchoEncoder; import ch.qos.logback.core.util.CoreTestConstants; /** - * * Do not forget to call start() when configuring programatically. - * + * * @author Ceki Gülcü * @author Sébastien Pennec - * */ public class SizeBasedRollingTest extends ScaffoldingForRollingTests { @@ -45,13 +48,13 @@ public class SizeBasedRollingTest extends ScaffoldingForRollingTests { super.setUp(); { File target = new File(CoreTestConstants.OUTPUT_DIR_PREFIX - + "sizeBased-smoke.log"); + + "sizeBased-smoke.log"); target.mkdirs(); target.delete(); } { File target = new File(CoreTestConstants.OUTPUT_DIR_PREFIX - + "sbr-test3.log"); + + "sbr-test3.log"); target.mkdirs(); target.delete(); } @@ -83,7 +86,7 @@ public class SizeBasedRollingTest extends ScaffoldingForRollingTests { sbtp.setMaxFileSize("100"); sbtp.start(); fwrp.setFileNamePattern(CoreTestConstants.OUTPUT_DIR_PREFIX - + "sizeBased-test1.%i"); + + "sizeBased-test1.%i"); try { fwrp.start(); fail("The absence of activeFileName option should have caused an exception."); @@ -125,7 +128,7 @@ public class SizeBasedRollingTest extends ScaffoldingForRollingTests { String prefix = "hello"; for (int i = 0; i < runLength; i++) { Thread.sleep(10); - rfa.doAppend(prefix+i); + rfa.doAppend(prefix + i); } expectedFilenameList.add(randomOutputDir + "a-sizeBased-smoke.log"); @@ -167,12 +170,12 @@ public class SizeBasedRollingTest extends ScaffoldingForRollingTests { String prefix = "hello"; for (int i = 0; i < runLength; i++) { Thread.sleep(10); - rfa.doAppend("hello"+i); + rfa.doAppend("hello" + i); } - expectedFilenameList.add(randomOutputDir + "a-sbr-test3.log"); - expectedFilenameList.add(randomOutputDir + "sbr-test3.0.gz"); - expectedFilenameList.add(randomOutputDir + "sbr-test3.1.gz"); + expectedFilenameList.add(randomOutputDir + "a-sbr-test3.log"); + expectedFilenameList.add(randomOutputDir + "sbr-test3.0.gz"); + expectedFilenameList.add(randomOutputDir + "sbr-test3.1.gz"); existenceCheck(expectedFilenameList); reverseSortedContentCheck(randomOutputDir, runLength, prefix); @@ -206,11 +209,11 @@ public class SizeBasedRollingTest extends ScaffoldingForRollingTests { String prefix = "hello"; for (int i = 0; i < runLength; i++) { Thread.sleep(10); - rfa.doAppend("hello"+i); + rfa.doAppend("hello" + i); } - expectedFilenameList.add(randomOutputDir + "a-sbr-test3.log"); - expectedFilenameList.add(randomOutputDir + "sbr-test3.0.zip"); - expectedFilenameList.add(randomOutputDir + "sbr-test3.1.zip"); + expectedFilenameList.add(randomOutputDir + "a-sbr-test3.log"); + expectedFilenameList.add(randomOutputDir + "sbr-test3.0.zip"); + expectedFilenameList.add(randomOutputDir + "sbr-test3.1.zip"); existenceCheck(expectedFilenameList); reverseSortedContentCheck(randomOutputDir, runLength, prefix); @@ -219,17 +222,25 @@ public class SizeBasedRollingTest extends ScaffoldingForRollingTests { } - private void zipEntryNameCheck(List<String> expectedFilenameList) { - for(String filepath: expectedFilenameList) { - if(filepath.endsWith(".zip")) { - checkZipEntyName(filepath, "sbr-test3.%i.zip"); + private void zipEntryNameCheck(List<String> expectedFilenameList) throws IOException { + for (String filepath : expectedFilenameList) { + if (filepath.endsWith(".zip")) { + checkZipEntryName(filepath, "sbr-test3.%i.zip"); } } } SimpleDateFormat SDF = new SimpleDateFormat(); - private void checkZipEntyName(String filepath, String pattern) { - fail("to be continued"); + + private void checkZipEntryName(String filepath, String pattern) throws IOException { + System.out.println("Checking ["+filepath+"]"); + ZipFile zf = new ZipFile(filepath); + Enumeration entries = zf.entries(); + assert(entries.hasMoreElements()); + ZipEntry firstZipEntry = (ZipEntry) entries.nextElement(); + assert(!entries.hasMoreElements()); + System.out.println("Testing zip entry ["+firstZipEntry.getName()+"]"); + assertTrue(firstZipEntry.getName().matches("sbr-test3.20\\d{2}-\\d{2}-\\d{2}_\\d{4}")); } } diff --git a/logback-core/src/test/scala/ch/qos/logback/core/rolling/LBCORE_199.scala b/logback-core/src/test/scala/ch/qos/logback/core/rolling/LBCORE_199.scala index 8dcb859..1d79982 100644 --- a/logback-core/src/test/scala/ch/qos/logback/core/rolling/LBCORE_199.scala +++ b/logback-core/src/test/scala/ch/qos/logback/core/rolling/LBCORE_199.scala @@ -36,7 +36,6 @@ class LBCORE_199 extends RollingScaffolding { @Test def smoke() { - println("ba") initRFA("toto.log") fwrp.setFileNamePattern("tests.%i.log.zip") fwrp.minIndex = 1 ----------------------------------------------------------------------- Summary of changes: .../core/rolling/FixedWindowRollingPolicy.java | 4 +- .../logback/core/rolling/SizeBasedRollingTest.java | 53 ++++++++++++-------- .../ch/qos/logback/core/rolling/LBCORE_199.scala | 1 - 3 files changed, 35 insertions(+), 23 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[JIRA] Created: (LBCLASSIC-270) Logback throws NP Exception when trying to use groovy configuration file.
by Nicolai Marck Ødum (JIRA) 25 May '11

25 May '11

Logback throws NP Exception when trying to use groovy configuration file. ------------------------------------------------------------------------- Key: LBCLASSIC-270 URL: http://jira.qos.ch/browse/LBCLASSIC-270 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.29 Environment: Has been verifed on both Linux and Windows and Oracle "standard" JVM and Oracle JRockit. slf4j-api.jar logback-classic.jar and logback-core.jar should be in %JRE_HOME%/lib/endorsed folder Start applikation with -Dlogback.configurationFile=<somewhere>/logback.groovy Reporter: Nicolai Marck Ødum Assignee: Logback dev list If logback jars (logback-claaic and logback-core) are located in endorsed libraries ( -Djava.endorsed.dirs) its not possible to use a logback configuration url that ends with groovy. This is because of line 23 in ch.qos.logback.classic.util.EnvUtil ClassLoader classLoader = EnvUtil.class.getClassLoader(); witch return null if called from endorsed libraries. It should work if you change it to ClassLoader classLoader = EnvUtil.class.getClassLoader(); if (classLoader == null) classLoader = ClassLoader.getSystemClassLoader(); I have not been able to verify this fix since I am not able to build logback :-( -- 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-269) [Backward compatibility] Unable to use multiple logback-test.xml config files
by Olivier Dupré (JIRA) 25 May '11

25 May '11

[Backward compatibility] Unable to use multiple logback-test.xml config files ----------------------------------------------------------------------------- Key: LBCLASSIC-269 URL: http://jira.qos.ch/browse/LBCLASSIC-269 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.28 Environment: Maven 2 Reporter: Olivier Dupré Assignee: Logback dev list Priority: Minor Hi, I think I'm facing a backward compatibily issue with logback 0.9.28. I have multi-modules projects with maven. I used to have multiple logback-test.xml files, one per test/resources folder per module. With logback v0.9.26 logback used to consider each logback-test config file, and use the appropriate file for each module. Now, logback only considers the very first logback configuration found while testing the multi-module project. Is that the expected behavior? Thanks in advance, Olivier. -- 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-82) Allow an Appender to be added to a Logger with a Level for more fine grained control of logging output
by Robert Elliot (JIRA) 20 May '11

20 May '11

Allow an Appender to be added to a Logger with a Level for more fine grained control of logging output ------------------------------------------------------------------------------------------------------ Key: LBCLASSIC-82 URL: http://jira.qos.ch/browse/LBCLASSIC-82 Project: logback-classic Issue Type: New Feature Components: appender, joran Environment: N/A Reporter: Robert Elliot Assignee: Logback dev list Priority: Minor Here's my use case: I have an appender, standard.log, whose job is to log major system events such as startup and shutdown, and all problems. I have configured my logger levels very carefully to ensure I get exactly the output I want - in some cases suppressing WARN messages that I know are not a problem by setting the level to ERROR, in some cases allowing INFO messages that let me see important lifecycle events. A simplified example might look like this: root=WARN,standard.log x.y=INFO a=ERROR I have a problem in a couple of parts of the system which means I want to turn on debug logging for that part of the system. I want the output of this to go to a separate appender - debug.log. So now my config looks like this: root=WARN,standard.log x.y=INFO x.y.z=DEBUG,debug.log a=ERROR a.b=DEBUG,debug.log But now I have an issue; all my debug statements are going to standard.log. It is being polluted with a load of information I don't want in it. I have several options: 1) Set additivity to false on x.y.z and a.b. But then any ERROR messages in a.b or INFO or above messages in x.y.z no longer get to standard.log, so this won't do 2) Add a filter of INFO or greater to the standard.log appender But then any INFO and WARN messages in a.b will get to standard.log - and I only want ERROR messages from a and its descendants in there 3) Add a filter of WARN or greater to the standard.log appender Now I still get the WARN messages from a.b that I don't want - and I've lost the INFO messages from x.y that I do want 4) Create two new appenders, standard.log2 for a and standard.log3 for x.y.z. Add a filter to standard.log2 so that it only accepts ERROR. Add a filter to standard.log3 so it only accepts INFO or above. Set additivity to false on a and x.y.z. That works. But it's a huge amount of added configuration, and that would rapidly multiply in a real world setting. 5) Create a custom filter for standard.log which would effectively mirror the logger config by querying the event for its logger and and level. That blows DRY out of the water, of course, and again is a large amount of work for a simple use case. My suggestion to make this easy is to allow Appenders to be added to a Logger with a Level. This solution would operate in parallel with the existing solution, and would not alter the existing behaviour one iota. This would allow me to add debug,log as an appender on a and x.y.z with a level of debug. All debug statements in a and x.y.z & their descendants would be appended to that appender. All statements would also be passed to the "normal" appender and logger hierarchy, so standard.log would still get the same output as before. I have written unit tests for this behaviour and attach a patch fulfilling them; I hope the unit tests flesh out any queries you may have around how this behaves in edge cases. The only change to the public API is a new method addAppender(Appender<LoggingEvent> newAppender, Level level) on Logger. The only change to the config format is allowing an optional level attribute on appender-ref. -- 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

Setting up DB Appender with Oracle
by auwall 16 May '11

16 May '11

I am having problems setting up a dbappender with an oracle database. The version of oracle i'm using is oracle 11 gr 2 and i downloaded it's corresponding jdbc drivers (ojdbc6 from oracle) Here is my config for it <appender name="DB2" class="ch.qos.logback.classic.db.DBAppender"> <connectionSource class="ch.qos.logback.core.db.DriverManagerConnectionSource"> <driverClass>oracle.jdbc.driver.OracleDriver</driverClass> <url>jdbc:oracle:thin:@XX.XX.XX.XX:MYSID</url> <user>ME</user> <password>MYPASSWORD</password> </connectionSource> </appender> but i'm getting these errors: 19:53:25,311 |-WARN in ch.qos.logback.core.db.DriverManagerConnectionSource@69e328e0 - Could not discover the dialect to use. java.sql.SQLRecoverableException: IO Error: The Network Adapter could not establish the connection at java.sql.SQLRecoverableException: IO Error: The Network Adapter could not establish the connection at at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:419) at at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:536) at at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:228) at at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:32) at at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:521) at at java.sql.DriverManager.getConnection(DriverManager.java:582) at at java.sql.DriverManager.getConnection(DriverManager.java:185) at at ch.qos.logback.core.db.DriverManagerConnectionSource.getConnection(DriverManagerConnectionSource.java:54) at at ch.qos.logback.core.db.ConnectionSourceBase.discoverConnnectionProperties(ConnectionSourceBase.java:47) at at ch.qos.logback.core.db.DriverManagerConnectionSource.start(DriverManagerConnectionSource.java:38) at at ch.qos.logback.core.joran.action.NestedComplexPropertyIA.end(NestedComplexPropertyIA.java:167) at at ch.qos.logback.core.joran.spi.Interpreter.callEndAction(Interpreter.java:315) at at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:194) at at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:180) at at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:52) at at ch.qos.logback.core.joran.spi.Interpreter.play(Interpreter.java:332) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:126) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:93) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:52) at at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:77) at at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:150) at at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:85) at at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55) at at org.slf4j.LoggerFactory.bind(LoggerFactory.java:121) at at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:111) at at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:268) at at package.MyClass.main(LogManagerTest.java:35) Caused by: oracle.net.ns.NetException: The Network Adapter could not establish the connection at at oracle.net.nt.ConnStrategy.execute(ConnStrategy.java:375) at at oracle.net.resolver.AddrResolution.resolveAndExecute(AddrResolution.java:422) at at oracle.net.ns.NSProtocol.establishConnection(NSProtocol.java:678) at at oracle.net.ns.NSProtocol.connect(NSProtocol.java:238) at at oracle.jdbc.driver.T4CConnection.connect(T4CConnection.java:1054) at at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:308) at ... 26 common frames omitted Caused by: java.net.NoRouteToHostException: No route to host at at java.net.PlainSocketImpl.socketConnect(Native Method) at at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at at java.net.Socket.connect(Socket.java:529) at at oracle.net.nt.TcpNTAdapter.connect(TcpNTAdapter.java:209) at at oracle.net.nt.ConnOption.connect(ConnOption.java:123) at at oracle.net.nt.ConnStrategy.execute(ConnStrategy.java:353) at ... 31 common frames omitted 19:53:25,316 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@36:14 - RuntimeException in Action for tag [appender] java.lang.IllegalStateException: DBAppender cannot function if the JDBC driver does not support getGeneratedKeys method *and* without a specific SQL dialect at java.lang.IllegalStateException: DBAppender cannot function if the JDBC driver does not support getGeneratedKeys method *and* without a specific SQL dialect at at ch.qos.logback.core.db.DBAppenderBase.start(DBAppenderBase.java:62) at at ch.qos.logback.classic.db.DBAppender.start(DBAppender.java:96) at at ch.qos.logback.core.joran.action.AppenderAction.end(AppenderAction.java:96) at at ch.qos.logback.core.joran.spi.Interpreter.callEndAction(Interpreter.java:315) at at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:194) at at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:180) at at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:52) at at ch.qos.logback.core.joran.spi.Interpreter.play(Interpreter.java:332) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:126) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:93) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:52) at at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:77) at at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:150) at at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:85) at at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55) at at org.slf4j.LoggerFactory.bind(LoggerFactory.java:121) at at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:111) at at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:268) at at package.main(LogManagerTest.java:35) 19:53:25,316 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [Service Management CSCI] to DEBUG 19:53:25,316 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[Service Management CSCI] 19:53:25,318 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to DEBUG -- View this message in context: http://old.nabble.com/Setting-up-DB-Appender-with-Oracle-tp31632497p3163249… Sent from the Logback Dev mailing list archive at Nabble.com.

1 0

Syslog Appender
by auwall 15 May '11

15 May '11

I am having trouble getting the syslog appender to work. I'm just trying to get a syslog appender to work in the most basic way. I copied the text from the logback documentation to set up my syslog appender. All i changed was the facility to USER and the host name to my ip address. When i log to the syslog appender i get no errors, but nothing is showing up in my system log file. I think it may have to do with this "When testing this configuration, you should verify that the remote syslog daemon accepts requests from an external source. Experience shows that, by default, syslog daemons usually deny requests coming via a network connection." So my question is: how can i find out if the syslog daemon running on my machine accepts requests coming via network connection and if it doesn't how do i go about making it accept them? Any help and direction would be appreciated. Thanks -- View this message in context: http://old.nabble.com/Syslog-Appender-tp31623948p31623948.html Sent from the Logback Dev mailing list archive at Nabble.com.

1 0

[JIRA] Created: (LBCORE-205) SocketAppender is causing a classloader leak
by Joern Huxhorn (JIRA) 13 May '11

13 May '11

SocketAppender is causing a classloader leak -------------------------------------------- Key: LBCORE-205 URL: http://jira.qos.ch/browse/LBCORE-205 Project: logback-core Issue Type: Bug Components: Appender Affects Versions: 0.9.28 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: /opt/local/share/java/maven3 Java version: 1.6.0_24, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: "mac os x", version: "10.6.7", arch: "x86_64", family: "mac" Tomcat 7.0.12 Reporter: Joern Huxhorn Assignee: Logback dev list Priority: Critical A classloader leak is caused by SocketAppender which prevents webapps from being properly undeployed and garbage collected. Steps to reproduce: 1.) Download and start Lilith. A server needs to be running and accepting the connection of the SocketAppender. Otherwise the leak will not happen. 2.) Build the webapp at https://github.com/huxi/lilith/tree/master/sandbox/logback-access-sandbox You can toggle the warning by removing or adding the SocketAppender in logback.xml. 3.) Deploy the webapp on Tomcat 7.0.12. 4.) Produce some events by accessing the webapp. 5.) Undeploy the webapp. 6.) Click on "Find leaks". Clicking on "Find leaks" causes the following message to be emitted: The following web applications were stopped (reloaded, undeployed), but their classes from previous runs are still loaded in memory, thus causing a memory leak (use a profiler to confirm): /lb-access-sandbox Unfortunately, there is no other information in any log file. The above warning message disappears if the logback-classic SocketAppender is removed from the configuration. I stumbled upon this issue while fixing http://sourceforge.net/apps/trac/lilith/ticket/96 -- 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-266) mssql.sql file has invalid schema
by Sumit Khanna (JIRA) 12 May '11

12 May '11

mssql.sql file has invalid schema ---------------------------------- Key: LBCLASSIC-266 URL: http://jira.qos.ch/browse/LBCLASSIC-266 Project: logback-classic Issue Type: Bug Components: appender Affects Versions: 0.9.28 Environment: Java 1.6 / Apache Tomcat 6 / SuSE Enterprise / Microsoft SQL Server 2005 - 9.00.4035.00 (x64 Enterprise Edition) Reporter: Sumit Khanna Assignee: Logback dev list In the file logback-0.9.28\logback-classic\src\main\java\ch\qos\logback\classic\db\dialect\mssql.sql, the type of DECIMAL(40) is invalid in SQL Server 2005. I had to change it to 38 to create the table. I apologize if this is a duplicate. I did a search and couldn't find any relevant bugs, but noticed in the source file the following commnet: -- The event_id column type was recently changed from INT to DECIMAL(40) -- without testing. -- 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: (LBCORE-208) No <meta http-equiv> header for log file is written by HTMLLayoutBase
by Vladislav Rastrusny (JIRA) 08 May '11

08 May '11

No <meta http-equiv> header for log file is written by HTMLLayoutBase --------------------------------------------------------------------- Key: LBCORE-208 URL: http://jira.qos.ch/browse/LBCORE-208 Project: logback-core Issue Type: Improvement Components: Layout Affects Versions: 0.9.9 Environment: Java Reporter: Vladislav Rastrusny Assignee: Logback dev list Priority: Minor When you use HTMLLayout for log files, logback only sets this HTML header: {code}<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html> <head> <title>Logback Log Messages</title> <style type="text/css"> </style> </head>{code} But if the log file contains symbols beyond ASCII range, some browsers can incorrectly set encoding displaying the file. My FireFox assumed my log file is in ISO-8859-5 when displaying it to me. Since Java strings are UTF-16 and log is composed of strings, it seems desired to have something like {code}<meta http-equiv="Content-Type" content="text/html; charset=utf-16">{code} in the HTML header. To add this functionality you only need to patch logback-core-0.9.28-sources.jar\ch\qos\logback\core\html\HTMLLayoutBase.getFileHeader() method adding this string to the list. But it would also be desired to have file header customizable from config file. -- 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

Deleting old RollingFileAppender log files
by Greg Thomas 05 May '11

05 May '11

There's a ticket open - http://jira.qos.ch/browse/LBCORE-147 - that it causing me grief. I'd like to offer to have a go at fixing it. The problem as I see it is that if you keep, for example, 7 days worth of log files, then ... On day 8, the appender deletes the log file for day 1 On day 9, the appender deletes the log file for day 2 (Day 10 has no activity) On day 11, the appender deletes the log file for day 4 So, the log file for day 3 hangs around indefinitely until it's tidied up manually. I can see two possible solutions for this; a) Search back for a configurable amount of time, and delete more than one log file. So with the above example with a 1 day search back window, On day 8, the appender deletes the log files for day 1 and day 0 if they exist. On day 9, the appender deletes the log files for day 2 and day 1 if they exist. (Day 10 has no activity) On day 11, the appender deletes the log files for day 4 and day 3 if they exist. b) Check the contents of the directory that the log files are stored in, and delete all those that are older than the required time, so ... On day 8, the appender checks the directory, and finds that the file for day 1 has a name pattern that is over 7 days old, and deletes it. On day 9, the appender checks the directory, and finds that the file for day 2 has a name pattern that is over 7 days old, and deletes it. (Day 10 has no activity) On day 11, the appender checks the directory, and finds that the file for days 3 and 4 have a name pattern that is over 7 days old, and deletes them. I think my preference is probably for option a), but I'd rather spend the time and effort implementing something that is more likely to be accepted as a patch. What do the maintainers think is the correct way to fix this issue? Thanks, Greg

1 0