October 2008 - logback-dev - mailman3.qos.ch

[JIRA] Updated: (LBCLASSIC-35) Deadlock when running on multiple core processors
by Ralph Goers (JIRA) 16 Oct '08

16 Oct '08

[ http://jira.qos.ch/browse/LBCLASSIC-35?page=com.atlassian.jira.plugin.syste… ] Ralph Goers updated LBCLASSIC-35: --------------------------------- Attachment: patch2.txt Updated patch. This one makes the Appender name required and immutable, removes all the synchronization from Logger and makes sure that an AppenderAttachableImpl is always attached to the Logger eliminating any race conditions that might occur during reconfiguration. > Deadlock when running on multiple core processors > ------------------------------------------------- > > Key: LBCLASSIC-35 > URL: http://jira.qos.ch/browse/LBCLASSIC-35 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: Windows > Platform: PC > Reporter: Toni Heimala > Assignee: Ceki Gulcu > Priority: Blocker > Attachments: patch.txt, patch2.txt > > > When you run logging into same file from many threads on a system that has more than one physical processor (Dual Core for example), a deadlock will occur after a while. This can not be reproduced on HyperThreading processors. Here's an example program that will demonstrate the behavior: > ----------------------------- > Main.java > ----------------------------- > import java.util.Date; > import java.util.concurrent.ScheduledThreadPoolExecutor; > import java.util.concurrent.TimeUnit; > import org.slf4j.Logger; > import org.slf4j.LoggerFactory; > import ch.qos.logback.classic.LoggerContext; > import ch.qos.logback.classic.joran.JoranConfigurator; > import ch.qos.logback.core.joran.spi.JoranException; > public class Main extends Thread > { > private final static String LOGGER_CONFIGURATION_FILE = "logger.xml"; > private final Logger logger = LoggerFactory.getLogger(Main.class); > > private final long start; > > public Main() > throws JoranException > { > start = new Date().getTime(); > LoggerContext lc = (LoggerContext)LoggerFactory.getILoggerFactory(); > JoranConfigurator configurator = new JoranConfigurator(); > lc.shutdownAndReset(); > configurator.setContext(lc); > configurator.doConfigure(LOGGER_CONFIGURATION_FILE); > } > > public void start() > { > ScheduledThreadPoolExecutor ex1 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex2 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex3 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex4 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex5 = new ScheduledThreadPoolExecutor(1); > ex1.scheduleAtFixedRate(new Task("EX1"), 10, 10, TimeUnit.MICROSECONDS); > ex2.scheduleAtFixedRate(new Task("EX2"), 10, 10, TimeUnit.MICROSECONDS); > ex3.scheduleAtFixedRate(new Task("EX3"), 10, 10, TimeUnit.MICROSECONDS); > ex4.scheduleAtFixedRate(new Task("EX4"), 10, 10, TimeUnit.MICROSECONDS); > ex5.scheduleAtFixedRate(new Task("EX5"), 10, 10, TimeUnit.MICROSECONDS); > > super.start(); > } > > public void run() > { > try > { > while(true) > { > logger.debug("[MAIN] {}", new Date().getTime() - start); > Thread.sleep(10); > } > } > catch (InterruptedException e) > { > logger.info("[MAIN]: Interrupted: {}", e.getMessage()); > } > } > > public static void main(String[] args) > { > try > { > Main main = new Main(); > main.start(); > } > catch (JoranException e) > { > System.out.println("Failed to load application: " + e.getMessage()); > } > } > } > ------------------------------- > Task.java > ------------------------------- > import java.util.Date; > import org.slf4j.Logger; > import org.slf4j.LoggerFactory; > public class Task implements Runnable > { > private final Logger logger = LoggerFactory.getLogger(Task.class); > private final Logger logger_main = LoggerFactory.getLogger(Main.class); > private final String name; > private final long start; > > public Task(final String name) > { > this.name = name; > start = new Date().getTime(); > } > public void run() > { > logger.debug("[{}] {}", name, new Date().getTime() - start); > logger_main.debug("[MAIN] - [{}] {}", name, new Date().getTime() - start); > } > } -- 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] Commented: (LBCORE-47) JMS Appender Fails - Odd Interaction with Commons Logging
by Ceki Gulcu (JIRA) 15 Oct '08

15 Oct '08

[ http://jira.qos.ch/browse/LBCORE-47?page=com.atlassian.jira.plugin.system.i… ] Ceki Gulcu commented on LBCORE-47: ---------------------------------- Todd, Thank you for supplying a testbed. It made it easier to reproduce the problem. The problem can be described as follows: 1) In the static initializer of the LoggerFactory class, the result of StaticLoggerBinder.SINGLETON.getLoggerFactory() is assigned to the loggerFactory variable 2) the StaticLoggerBinder.SINGLETON.getLoggerFactory() call, instantiates a logback LoggerContext which proceeds with auto-initialization. 3) auto-initialization reads the config file which creates a .ActiveMQInitialContextFactory 4) this ActiveMQInitialContextFactory class performs logging via commons-logging. However, at this stage the loggerFactory variable is not yet assigned. Hence the error. There are several ways to solve this problem. A) assign loggerFactory to a nopFactory value just before calling StaticLoggerBinder.SINGLETON.getLoggerFactory() B) have LoggerFactory invoke auto-initialization as a second step after the loggerFactory variable is assigned. This would require the addition of a new method, say autoInitialize()w to the ILoggerFactory interface. C) Have logback perform auto-initialization in two steps. In the first step only non-re-entrant appenders are configured. Re-entrant appenders are left as a job to be performed by a different thread a later time. This is too complicated a solution to be further discussed. Approach A implies that a NOPLogger needs to be merged into slf4j-api. Approach B would work very well with logback. However, this bug is not logback specific, if log4j were the underlying logging system, then it would still occur. Given that log4j is not a native SLF4J implementation without knowledge of the ILoggerFactory.autoInitialize() method, approach B is not valid for log4j. I guess that just leaves A. > JMS Appender Fails - Odd Interaction with Commons Logging > --------------------------------------------------------- > > Key: LBCORE-47 > URL: http://jira.qos.ch/browse/LBCORE-47 > Project: logback-core > Issue Type: Bug > Components: Appender > Affects Versions: unspecified > Environment: Operating System: Windows > Platform: PC > Reporter: todd orr > Assignee: Ceki Gulcu > Priority: Blocker > Attachments: testbed.zip > > > I'm not sure exactly what's going on, but I've been able to determine that the JMS appender doesn't work under certain circumstances due to some interaction with commons logging. > Here is my maven POM: > <?xml version="1.0" encoding="UTF-8"?> > <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> > <modelVersion>4.0.0</modelVersion> > <groupId>foo.bar</groupId> > <artifactId>testbed</artifactId> > <name>Testbed</name> > <packaging>jar</packaging> > <version>0.1-SNAPSHOT</version> > <build> > <plugins> > <plugin> > <artifactId>maven-compiler-plugin</artifactId> > <configuration> > <source>1.5</source> > <target>1.5</target> > </configuration> > </plugin> > </plugins> > </build> > <dependencies> > <dependency> > <groupId>org.apache.activemq</groupId> > <artifactId>activemq-core</artifactId> > <version>5.0.0</version> > <exclusions> > <exclusion> > <groupId>commons-logging</groupId> > <artifactId>commons-logging</artifactId> > </exclusion> > <exclusion> > <groupId>commons-logging</groupId> > <artifactId>commons-logging-api</artifactId> > </exclusion> > </exclusions> > </dependency> > <dependency> > <groupId>org.slf4j</groupId> > <artifactId>slf4j-api</artifactId> > <version>1.4.3</version> > </dependency> > <dependency> > <groupId>org.slf4j</groupId> > <artifactId>jcl104-over-slf4j</artifactId> > <version>1.4.3</version> > </dependency> > <dependency> > <groupId>ch.qos.logback</groupId> > <artifactId>logback-core</artifactId> > <version>0.9.9</version> > </dependency> > <dependency> > <groupId>ch.qos.logback</groupId> > <artifactId>logback-classic</artifactId> > <version>0.9.9</version> > </dependency> > </dependencies> > </project> > Here is my logback config: > <configuration debug="true"> > <appender name="STDOUT" > class="ch.qos.logback.core.ConsoleAppender"> > <layout class="ch.qos.logback.classic.PatternLayout"> > <Pattern> > %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n > </Pattern> > </layout> > </appender> >  > <root> > <level value="TRACE" /> > <appender-ref ref="STDOUT" /> > </root> > </configuration> > Uncommenting the QUEUE appender results in the following stack trace: > Failed to instantiate [ch.qos.logback.classic.LoggerContext] > Reported exception: > java.lang.ExceptionInInitializerError > at org.apache.activemq.ActiveMQConnectionFactory.<init>(ActiveMQConnectionFactory.java:88) > at org.apache.activemq.ActiveMQConnectionFactory.<init>(ActiveMQConnectionFactory.java:121) > at org.apache.activemq.ActiveMQConnectionFactory.<init>(ActiveMQConnectionFactory.java:117) > at org.apache.activemq.jndi.ActiveMQInitialContextFactory.createConnectionFactory(ActiveMQInitialContextFactory.java:201) > at org.apache.activemq.jndi.ActiveMQInitialContextFactory.createConnectionFactory(ActiveMQInitialContextFactory.java:140) > at org.apache.activemq.jndi.ActiveMQInitialContextFactory.getInitialContext(ActiveMQInitialContextFactory.java:65) > at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667) > at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247) > at javax.naming.InitialContext.init(InitialContext.java:223) > at javax.naming.InitialContext.<init>(InitialContext.java:197) > at ch.qos.logback.core.net.JMSAppenderBase.buildJNDIContext(JMSAppenderBase.java:49) > at ch.qos.logback.classic.net.JMSQueueAppender.start(JMSQueueAppender.java:89) > at ch.qos.logback.core.joran.action.AppenderAction.end(AppenderAction.java:89) > at ch.qos.logback.core.joran.spi.Interpreter.callEndAction(Interpreter.java:310) > at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:173) > at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:154) > at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:48) > at ch.qos.logback.core.joran.spi.Interpreter.play(Interpreter.java:336) > at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:96) > at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:74) > at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:38) > at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:23) > at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:34) > at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:43) > at org.slf4j.impl.StaticLoggerBinder.initialize(StaticLoggerBinder.java:62) > at org.slf4j.impl.StaticLoggerBinder.<init>(StaticLoggerBinder.java:53) > at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:48) > at org.slf4j.LoggerFactory.<clinit>(LoggerFactory.java:60) > at foo.bar.testbed.LoggerTester.main(LoggerTester.java:9) > Caused by: java.lang.IllegalStateException: Logging factory implementation cannot be null. See also http://www.slf4j.org/codes.html#null_LF > at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:86) > at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155) > at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:131) > at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:204) > at org.apache.activemq.ActiveMQPrefetchPolicy.<clinit>(ActiveMQPrefetchPolicy.java:30) > ... 29 more > Failed to instantiate logger [ch.qos.logback.classic.selector.ContextSelector] > Reported exception: > java.lang.IllegalStateException: contextSelector cannot be null. See also http://logback.qos.ch/codes.html#null_CS > at org.slf4j.impl.StaticLoggerBinder.getLoggerFactory(StaticLoggerBinder.java:98) > at org.slf4j.LoggerFactory.<clinit>(LoggerFactory.java:60) > at foo.bar.testbed.LoggerTester.main(LoggerTester.java:9) > Exception in thread "main" java.lang.IllegalStateException: Logging factory implementation cannot be null. See also http://www.slf4j.org/codes.html#null_LF > at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:101) > at foo.bar.testbed.LoggerTester.main(LoggerTester.java:9) > However, removing the SLF4J commons bridge and un-excluding the commons libs from activemq results in the correct behavior. At this point the commons logging is not running through SLF4J at this point. So this is not desirable. -- 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] Commented: (LBGENERAL-16) logback 0.9.8 keeps dropping and recreating connections
by Ceki Gulcu (JIRA) 15 Oct '08

15 Oct '08

[ http://jira.qos.ch/browse/LBGENERAL-16?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu commented on LBGENERAL-16: ------------------------------------- Sorry for my previous comment. I had not seen the previous comments. Anyway, if you print the contents of status messages, then you should get a much better idea of what is going on. > logback 0.9.8 keeps dropping and recreating connections > ------------------------------------------------------- > > Key: LBGENERAL-16 > URL: http://jira.qos.ch/browse/LBGENERAL-16 > Project: logback-general > Issue Type: Bug > Components: build-structure > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Joern Huxhorn > Assignee: Logback dev list > Priority: Blocker > > I have a serious problem with logback 0.9.8 that forced me to downgrade to 0.9.7 again. > The socket-appender keeps dropping and recreating connections, missing log-events in the process. It does so at least once, i.e. creating a connection without writing a single event and then closing it again immeditaly. > I tried to reporduce the behaviour in a simple test program but didn't succeed. Everything is fine in a simple test. > In both of our "real" applications, however, this problem is definitly reproducible and just vanishes after a downgrade to 0.9.7. I suspect that the problem is connected to log4j-over-slf4j because that's one of the differences to my small test. > We have the following dependencies: > <dependency> > <groupId>org.slf4j</groupId> > <artifactId>slf4j-api</artifactId> > <scope>compile</scope> > </dependency> > <dependency> > <groupId>commons-logging</groupId> > <artifactId>commons-logging</artifactId> > <scope>provided</scope> > </dependency> > <dependency> > <groupId>org.slf4j</groupId> > <artifactId>jcl104-over-slf4j</artifactId> > <scope>runtime</scope> > </dependency> > <dependency> > <groupId>org.slf4j</groupId> > <artifactId>log4j-over-slf4j</artifactId> > <scope>runtime</scope> > </dependency> > <dependency> > <groupId>log4j</groupId> > <artifactId>log4j</artifactId> > <scope>provided</scope> > </dependency> > <dependency> > <groupId>ch.qos.logback</groupId> > <artifactId>logback-core</artifactId> > <scope>compile</scope> > </dependency> > <dependency> > <groupId>ch.qos.logback</groupId> > <artifactId>logback-classic</artifactId> > <scope>compile</scope> > </dependency> > with slf4j 1.4.3 and logback 0.9.8 as version. > We use several third-party jars in our apps, e.g. spring, commons-stuff etc., so we have to map both commons-logging as well as log4j to logback. > This worked perfectly up to version 0.9.7 but doesn't work anymore! > I'm sorry about this rather obscure error report but I'm really quite clueless about the problem myself. I just checked the svn repos and the last socket appender change was done 4 month ago so that can't be responsible... > I'll try to investigate this some more but you might already know what's wrong since you know what changed between 0.9.7 and 0.9.8. > The problem exists on at least Windows and Solaris, btw. -- 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] Commented: (LBGENERAL-16) logback 0.9.8 keeps dropping and recreating connections
by Ceki Gulcu (JIRA) 15 Oct '08

15 Oct '08

[ http://jira.qos.ch/browse/LBGENERAL-16?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu commented on LBGENERAL-16: ------------------------------------- Joern, Is it possible that the client and server side use different logback versions? > logback 0.9.8 keeps dropping and recreating connections > ------------------------------------------------------- > > Key: LBGENERAL-16 > URL: http://jira.qos.ch/browse/LBGENERAL-16 > Project: logback-general > Issue Type: Bug > Components: build-structure > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Joern Huxhorn > Assignee: Logback dev list > Priority: Blocker > > I have a serious problem with logback 0.9.8 that forced me to downgrade to 0.9.7 again. > The socket-appender keeps dropping and recreating connections, missing log-events in the process. It does so at least once, i.e. creating a connection without writing a single event and then closing it again immeditaly. > I tried to reporduce the behaviour in a simple test program but didn't succeed. Everything is fine in a simple test. > In both of our "real" applications, however, this problem is definitly reproducible and just vanishes after a downgrade to 0.9.7. I suspect that the problem is connected to log4j-over-slf4j because that's one of the differences to my small test. > We have the following dependencies: > <dependency> > <groupId>org.slf4j</groupId> > <artifactId>slf4j-api</artifactId> > <scope>compile</scope> > </dependency> > <dependency> > <groupId>commons-logging</groupId> > <artifactId>commons-logging</artifactId> > <scope>provided</scope> > </dependency> > <dependency> > <groupId>org.slf4j</groupId> > <artifactId>jcl104-over-slf4j</artifactId> > <scope>runtime</scope> > </dependency> > <dependency> > <groupId>org.slf4j</groupId> > <artifactId>log4j-over-slf4j</artifactId> > <scope>runtime</scope> > </dependency> > <dependency> > <groupId>log4j</groupId> > <artifactId>log4j</artifactId> > <scope>provided</scope> > </dependency> > <dependency> > <groupId>ch.qos.logback</groupId> > <artifactId>logback-core</artifactId> > <scope>compile</scope> > </dependency> > <dependency> > <groupId>ch.qos.logback</groupId> > <artifactId>logback-classic</artifactId> > <scope>compile</scope> > </dependency> > with slf4j 1.4.3 and logback 0.9.8 as version. > We use several third-party jars in our apps, e.g. spring, commons-stuff etc., so we have to map both commons-logging as well as log4j to logback. > This worked perfectly up to version 0.9.7 but doesn't work anymore! > I'm sorry about this rather obscure error report but I'm really quite clueless about the problem myself. I just checked the svn repos and the last socket appender change was done 4 month ago so that can't be responsible... > I'll try to investigate this some more but you might already know what's wrong since you know what changed between 0.9.7 and 0.9.8. > The problem exists on at least Windows and Solaris, btw. -- 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

svn commit: r1840 - logback/trunk/logback-core/src/main/java/ch/qos/logback/core/net
by noreply.ceki＠qos.ch 15 Oct '08

15 Oct '08

Author: ceki Date: Wed Oct 15 21:27:54 2008 New Revision: 1840 Modified: logback/trunk/logback-core/src/main/java/ch/qos/logback/core/net/LoginAuthenticator.java Log: - copyright statement Modified: logback/trunk/logback-core/src/main/java/ch/qos/logback/core/net/LoginAuthenticator.java ============================================================================== --- logback/trunk/logback-core/src/main/java/ch/qos/logback/core/net/LoginAuthenticator.java (original) +++ logback/trunk/logback-core/src/main/java/ch/qos/logback/core/net/LoginAuthenticator.java Wed Oct 15 21:27:54 2008 @@ -1,3 +1,13 @@ +/** + * Logback: the generic, reliable, fast and flexible logging framework. + * + * Copyright (C) 2000-2008, QOS.ch + * + * This library is free software, you can redistribute it and/or modify it under + * the terms of the GNU Lesser General Public License as published by the Free + * Software Foundation. + */ + package ch.qos.logback.core.net; import javax.mail.Authenticator;

1 0

svn commit: r1839 - logback/trunk/logback-core/src/test/java/ch/qos/logback/core/pattern/parser
by noreply.ceki＠qos.ch 15 Oct '08

15 Oct '08

Author: ceki Date: Wed Oct 15 21:27:28 2008 New Revision: 1839 Modified: logback/trunk/logback-core/src/test/java/ch/qos/logback/core/pattern/parser/SamplePatternLayoutTest.java Log: new test case on parentheses closing in patterns Modified: logback/trunk/logback-core/src/test/java/ch/qos/logback/core/pattern/parser/SamplePatternLayoutTest.java ============================================================================== --- logback/trunk/logback-core/src/test/java/ch/qos/logback/core/pattern/parser/SamplePatternLayoutTest.java (original) +++ logback/trunk/logback-core/src/test/java/ch/qos/logback/core/pattern/parser/SamplePatternLayoutTest.java Wed Oct 15 21:27:28 2008 @@ -45,15 +45,28 @@ assertEquals("x123", s); } + + + @Test + public void testEscapeClosingParentheses() { + PatternLayoutBase<Object> plb = getPatternLayoutBase(); + Context context = new ContextBase(); + plb.setContext(context); + plb.setPattern("x(%OTT\\)y"); + plb.start(); + String s = plb.doLayout(new Object()); + assertEquals("x(123)y", s); + } + @Test - public void testParentheses() { + public void testEscapeBothParentheses() { PatternLayoutBase<Object> plb = getPatternLayoutBase(); Context context = new ContextBase(); plb.setContext(context); - plb.setPattern("x(%OTT\\)"); + plb.setPattern("x\\(%OTT\\)y"); plb.start(); String s = plb.doLayout(new Object()); - assertEquals("x(123)", s); + assertEquals("x(123)y", s); } @Test

1 0

[JIRA] Resolved: (LBCORE-23) Parser stops at ')'
by Ceki Gulcu (JIRA) 15 Oct '08

15 Oct '08

[ http://jira.qos.ch/browse/LBCORE-23?page=com.atlassian.jira.plugin.system.i… ] Ceki Gulcu resolved LBCORE-23. ------------------------------ Fix Version/s: 0.9.10 Resolution: Fixed "Fixed" with better documentation. > Parser stops at ')' > ------------------- > > Key: LBCORE-23 > URL: http://jira.qos.ch/browse/LBCORE-23 > Project: logback-core > Issue Type: Bug > Components: Pattern > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Jens Elkner > Assignee: Logback dev list > Priority: Blocker > Fix For: 0.9.10 > > > The Parser skips everything after incl. ')'. Try e.g. > <Pattern>%date{HH:mm:ss,SSS} [%thread] %-5level (%file:%line) - %message%n</Pattern> > and thus is completely useless. > Bummer! -- 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

svn commit: r1838 - logback/trunk/logback-site/src/site/pages/manual
by noreply.ceki＠qos.ch 15 Oct '08

15 Oct '08

Author: ceki Date: Wed Oct 15 21:20:08 2008 New Revision: 1838 Modified: logback/trunk/logback-site/src/site/pages/manual/layouts.html Log: LBCORE-23 Improvements to the section regarding parentheses in PatternLayout Modified: logback/trunk/logback-site/src/site/pages/manual/layouts.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/manual/layouts.html (original) +++ logback/trunk/logback-site/src/site/pages/manual/layouts.html Wed Oct 15 21:20:08 2008 @@ -361,13 +361,13 @@ In PatternLayout, parenthesis can be used to group conversion - patterns. It follows that the '(' and ')' carry special meaning - and need to be escaped to be used as literals. Parentheses can - be escaped by preceding the the opening and closing parenthesis - by backslash, but since backslash itself carries special meaning - in Java, we need two backslahes, as in "\\(" and "\\)". In - practice however, only the opening parenthesis needs to be - escaped to be used as a literal. + patterns. It follows that the '(' and ')' carry special meaning + and need to be escaped to be used as literals. Parentheses + can be escaped by preceding the the opening and closing + parenthesis by backslash, but since backslash itself carries + special meaning in Java, we need two backslashes, as in "\\(" and + "\\)". Note that strictly speaking, only the closing parenthesis + needs to be escaped to be used as a literal. As mentionned previously, certain conversion specifiers can @@ -1055,7 +1055,7 @@ In logback, parentheses within the pattern string are treated as grouping tokens. Thus, it is possible to group a sub-pattern - and apply formatting directives to that sub-pattern. + and apply formatting directives on that sub-pattern. For example, the pattern @@ -1079,7 +1079,7 @@ 13:09:40 [btpool0-7] INFO c.q.l.d.prime.NumberCruncherImpl - Found factor 2 - with the "%-30()" grouping applied it would be + with the "%-30()" grouping it would be 13:09:30 [main] DEBUG c.q.logback.demo.ContextListener - Classload hashcode is 13995234 13:09:30 [main] DEBUG c.q.logback.demo.ContextListener - Initializing for ServletContext @@ -1095,9 +1095,12 @@ The latter form is more comfortable to read, especially for long log files. - If you need to treat the parenthesis character as a literal, it - needs to be escaped by preceding the parentheses with a - backslash. As in, \(%d{HH:mm:ss.SSS} [%thread]\). + If you need to treat the parenthesis character as a literal, + they needs to be escaped by preceding each parenthesis with a + backslash. As in, \(%d{HH:mm:ss.SSS} + [%thread]\). Strictly speaking, only the closing parentesis + needs to be escaped. Thus, "%d [%thread]\)" is + equivalent to "\(%d [%thread]\)".

1 0

svn commit: r1837 - logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi
by noreply.ceki＠qos.ch 15 Oct '08

15 Oct '08

Author: ceki Date: Wed Oct 15 20:59:55 2008 New Revision: 1837 Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/PackagingDataCalculator.java Log: - removing superfluous system.out.println statement Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/PackagingDataCalculator.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/PackagingDataCalculator.java (original) +++ logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/PackagingDataCalculator.java Wed Oct 15 20:59:55 2008 @@ -164,7 +164,6 @@ return cpd; } Class type = bestEffortLoadClass(lastExactClassLoader, className); - System.out.println("********** type is null for class "+className); String version = getImplementationVersion(type); String codeLocation = getCodeLocation(type); cpd = new ClassPackagingData(codeLocation, version, false);

1 0

svn commit: r1836 - logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi
by noreply.ceki＠qos.ch 15 Oct '08

15 Oct '08

Author: ceki Date: Wed Oct 15 19:06:48 2008 New Revision: 1836 Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/PackagingDataCalculator.java Log: Under certain special circumstances (reproducible under Continuum on Linux) the bestEffortLoadClass returns null. Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/PackagingDataCalculator.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/PackagingDataCalculator.java (original) +++ logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/PackagingDataCalculator.java Wed Oct 15 19:06:48 2008 @@ -164,6 +164,7 @@ return cpd; } Class type = bestEffortLoadClass(lastExactClassLoader, className); + System.out.println("********** type is null for class "+className); String version = getImplementationVersion(type); String codeLocation = getCodeLocation(type); cpd = new ClassPackagingData(codeLocation, version, false); @@ -172,6 +173,9 @@ } String getImplementationVersion(Class type) { + if(type == null) { + return "na"; + } Package aPackage = type.getPackage(); if (aPackage != null) { String v = aPackage.getImplementationVersion(); @@ -238,8 +242,8 @@ /** * - * @param lastGuaranteedClassLoader - * may be null + * @param lastGuaranteedClassLoader may be null + * * @param className * @return */

1 0