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

[JIRA] Commented: (LBCLASSIC-46) ThrowableInformation should keep the Throwable cause hierarchy intact.
by Joern Huxhorn (JIRA) 29 Oct '08

29 Oct '08

[ http://jira.qos.ch/browse/LBCLASSIC-46?page=com.atlassian.jira.plugin.syste… ] Joern Huxhorn commented on LBCLASSIC-46: ---------------------------------------- After checking a bit of source, I think that this probably isn't exactly comparable to LBCLASSIC-72 :p Concerning ThrowableProxy i'd suggest the following structure: class ThrowableProxy { String throwableClassName; String message; StackTraceElementProxy[] stackTrace; ThrowableProxy cause; transient String stringRep; } The only downside would be that the "... x common frames omitted" message wouldn't be possible anymore. The question is, is it really necessary? I'd also suggest to create the string representation lazily on demand. I guess that we could save quite a big amount of time by lazy creation of string representations (in both ThrowableProxy, StackTraceElementProxy and also in case of LoggingEvent.getFormattedMessage()) when needed instead of, like it is right now, during creation of the logging event itself. It's also leaner in case of serialization. > ThrowableInformation should keep the Throwable cause hierarchy intact. > ---------------------------------------------------------------------- > > Key: LBCLASSIC-46 > URL: http://jira.qos.ch/browse/LBCLASSIC-46 > Project: logback-classic > Issue Type: Improvement > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Joern Huxhorn > Assignee: Logback dev list > Priority: Minor > > Instead of a String representation of the whole Throwable stack trace incl. cause ThrowableInformation should instead look like this: > public class ThrowableInformation implements Serializable > { > String throwableClassName; > String message; > StackTraceElement[] stackTrace; > ThrowableInformation cause; > } > I omitted get/set and private in this example. > StackTraceElement is perfectly Serializable and did also receive a public c'tor in Java 5 so I guess that the current ThrowableInformation is more or less a relict of log4j which had to stay compatible with older Java versions. > You could obviously keep the getThrowableStrRep() method for compatibility. > This bug is somewhat related to LBCLASSIC-45 because I think that ThrowableInformation should also, as LoggingEvent, be just a dumb data container with no real logic. > The logic to extract the relevant StackTraceElements should IMHO be moved either into Logger or into a static factory method of ThrowableInformation. -- 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: (LBCLASSIC-46) ThrowableInformation should keep the Throwable cause hierarchy intact.
by Joern Huxhorn (JIRA) 28 Oct '08

28 Oct '08

[ http://jira.qos.ch/browse/LBCLASSIC-46?page=com.atlassian.jira.plugin.syste… ] Joern Huxhorn commented on LBCLASSIC-46: ---------------------------------------- Please see LBCLASSIC-72 for an updated feature request concerning this problem. I'll add some more infos there. > ThrowableInformation should keep the Throwable cause hierarchy intact. > ---------------------------------------------------------------------- > > Key: LBCLASSIC-46 > URL: http://jira.qos.ch/browse/LBCLASSIC-46 > Project: logback-classic > Issue Type: Improvement > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Joern Huxhorn > Assignee: Logback dev list > Priority: Minor > > Instead of a String representation of the whole Throwable stack trace incl. cause ThrowableInformation should instead look like this: > public class ThrowableInformation implements Serializable > { > String throwableClassName; > String message; > StackTraceElement[] stackTrace; > ThrowableInformation cause; > } > I omitted get/set and private in this example. > StackTraceElement is perfectly Serializable and did also receive a public c'tor in Java 5 so I guess that the current ThrowableInformation is more or less a relict of log4j which had to stay compatible with older Java versions. > You could obviously keep the getThrowableStrRep() method for compatibility. > This bug is somewhat related to LBCLASSIC-45 because I think that ThrowableInformation should also, as LoggingEvent, be just a dumb data container with no real logic. > The logic to extract the relevant StackTraceElements should IMHO be moved either into Logger or into a static factory method of ThrowableInformation. -- 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: r1897 - in logback/trunk/logback-classic/src: main/java/ch/qos/logback/classic test/java/ch/qos/logback/classic
by noreply.ceki＠qos.ch 28 Oct '08

28 Oct '08

Author: ceki Date: Tue Oct 28 19:07:19 2008 New Revision: 1897 Added: logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/Foo.java logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/LoggerSerializationTest.java Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/Logger.java logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/LoggerTestHelper.java logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/PackageTest.java Log: fixes LBCLASSIC-74 Make ch.qos.logback.classic.Logger instances deserialize with a valid LoggerContext reference. This is accomplished by the readResolve() method which returns a Logger generated by org.slf4j.LoggerFactory which may or not be using the correct LoggerContext. However, that is probably the best we can do at that stage. Associated test case. Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/Logger.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/Logger.java (original) +++ logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/Logger.java Tue Oct 28 19:07:19 2008 @@ -10,12 +10,14 @@ package ch.qos.logback.classic; +import java.io.ObjectStreamException; import java.io.Serializable; import java.util.ArrayList; import java.util.Collections; import java.util.Iterator; import java.util.List; +import org.slf4j.LoggerFactory; import org.slf4j.Marker; import org.slf4j.spi.LocationAwareLogger; @@ -73,18 +75,12 @@ * synchronized on 'this' (Logger) protecting against simultaneous * re-configuration of this logger (a very unlikely scenario). * - * - * It is further assumed that the AppenderAttachableImpl is responsible for - * its internal synchronization and thread safety. Thus, we can get away with - * *not* synchronizing on the 'aai' (check null/ read) because - * - * 1) the 'aai' variable is immutable once set to non-null - * - * 2) 'aai' is getAndSet only within addAppender which is synchronized - * - * 3) all the other methods check whether 'aai' is null - * - * 4) AppenderAttachableImpl is thread safe + * It is further assumed that the AppenderAttachableImpl is responsible + * for its internal synchronization and thread safety. Thus, we can get away + * with *not* synchronizing on the 'aai' (check null/ read) because 1) the + * 'aai' variable is immutable once set to non-null 2) 'aai' is getAndSet + * only within addAppender which is synchronized 3) all the other methods + * check whether 'aai' is null 4) AppenderAttachableImpl is thread safe */ private transient AppenderAttachableImpl<LoggingEvent> aai; /** @@ -134,9 +130,8 @@ /** * Get a child by its suffix. * - * - * IMPORTANT: Calls to this method must be within a synchronized block on this - * logger! + * IMPORTANT: Calls to this method must be within a synchronized block on + * this logger! * * @param suffix * @return @@ -315,9 +310,8 @@ * extending this logger. For example, if this logger is named "x.y" and the * lastPart is "z", then the created child logger will be named "x.y.z". * - * - * IMPORTANT: Calls to this method must be within a syncronized block on this - * logger. + * IMPORTANT: Calls to this method must be within a syncronized block on + * this logger. * * @param lastPart * the suffix (i.e. last part) of the child logger name. This @@ -833,4 +827,16 @@ } filterAndLog(fqcn, marker, level, message, null, t); } + + /** + * After serialization, the logger instance does not know its LoggerContext. + * The best we can do here, is to return a logger with the same name as + * generated by LoggerFactory. + * + * @return Logger instance with the same name + * @throws ObjectStreamException + */ + protected Object readResolve() throws ObjectStreamException { + return LoggerFactory.getLogger(getName()); + } } Added: logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/Foo.java ============================================================================== --- (empty file) +++ logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/Foo.java Tue Oct 28 19:07:19 2008 @@ -0,0 +1,17 @@ +package ch.qos.logback.classic; + +import java.io.Serializable; + +class Foo implements Serializable { + private static final long serialVersionUID = 1L; + final Logger logger; + + Foo(Logger logger) { + this.logger = logger; + } + + void doFoo() { + logger.debug("hello"); + } +} + Added: logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/LoggerSerializationTest.java ============================================================================== --- (empty file) +++ logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/LoggerSerializationTest.java Tue Oct 28 19:07:19 2008 @@ -0,0 +1,55 @@ +package ch.qos.logback.classic; + +import java.io.ByteArrayInputStream; +import java.io.ByteArrayOutputStream; +import java.io.IOException; +import java.io.ObjectInputStream; +import java.io.ObjectOutputStream; + +import org.junit.After; +import org.junit.Before; +import org.junit.Test; + +public class LoggerSerializationTest { + + LoggerContext lc; + Logger logger; + + ByteArrayOutputStream bos; + ObjectOutputStream oos; + ObjectInputStream inputStream; + + @Before + public void setUp() throws Exception { + lc = new LoggerContext(); + lc.setName("testContext"); + logger = lc.getLogger(LoggerSerializationTest.class); + // create the byte output stream + bos = new ByteArrayOutputStream(); + oos = new ObjectOutputStream(bos); + } + + @After + public void tearDown() throws Exception { + lc = null; + logger = null; + oos.close(); + } + + @Test + public void serialization() throws IOException, ClassNotFoundException { + Foo foo = new Foo(logger); + foo.doFoo(); + Foo fooBack = writeAndRead(foo); + fooBack.doFoo(); + } + + private Foo writeAndRead(Foo foo) throws IOException, + ClassNotFoundException { + oos.writeObject(foo); + ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray()); + inputStream = new ObjectInputStream(bis); + + return (Foo) inputStream.readObject(); + } +} Modified: logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/LoggerTestHelper.java ============================================================================== --- logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/LoggerTestHelper.java (original) +++ logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/LoggerTestHelper.java Tue Oct 28 19:07:19 2008 @@ -19,7 +19,4 @@ } assertEquals(effectiveLevel, logger.getEffectiveLevel()); } - - - } \ No newline at end of file Modified: logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/PackageTest.java ============================================================================== --- logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/PackageTest.java (original) +++ logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/PackageTest.java Tue Oct 28 19:07:19 2008 @@ -20,6 +20,7 @@ suite.addTest(new JUnit4TestAdapter(DynamicLoggerContextTest.class)); suite.addTest(new JUnit4TestAdapter(PatternLayoutTest.class)); suite.addTestSuite(BasicLoggerTest.class); + suite.addTest(new JUnit4TestAdapter(LoggerSerializationTest.class)); suite.addTestSuite(MessageFormattingTest.class); suite.addTestSuite(MDCTest.class); suite.addTestSuite(TurboFilteringInLoggerTest.class);

1 0

[JIRA] Commented: (LBCORE-1) Appender interface managing Layouts?
by Joern Huxhorn (JIRA) 28 Oct '08

28 Oct '08

[ http://jira.qos.ch/browse/LBCORE-1?page=com.atlassian.jira.plugin.system.is… ] Joern Huxhorn commented on LBCORE-1: ------------------------------------ This isn't exactly a duplicate of LBCORE-56 as that report is about AppenderBase, not the Appender interface itself. The Appender should probably only be concerned about basic appender functionality, i.e. doAppend and get/setName(). Those are both absolutely required by every Appender. set/getLayout, as well as the methods contained in LifeCycle, ContextAware and FilterAttachable, are not really necessary in every type of appender so I'd even suggest to remove the whole 'extends' section from the interface. I fully understand that this would mean a severe refactoring but it would ultimately result in cleaner Appender implementations that would only implement the supported part of the API. That's just an idea and nothing absolutely necessary so just ignore it if you don't like it :) > Appender interface managing Layouts? > ------------------------------------ > > Key: LBCORE-1 > URL: http://jira.qos.ch/browse/LBCORE-1 > Project: logback-core > Issue Type: Bug > Components: Appender > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Sébastien Pennec > Assignee: Logback dev list > Fix For: unspecified > > > Why does the c.p.l.core.Appender interface includes a getter and a setter for Layout? -- 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: r1896 - logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/pattern
by noreply.ceki＠qos.ch 28 Oct '08

28 Oct '08

Author: ceki Date: Tue Oct 28 17:54:42 2008 New Revision: 1896 Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/pattern/DateConverter.java Log: Add comment in relation to LBCLASSIC-36 Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/pattern/DateConverter.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/pattern/DateConverter.java (original) +++ logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/pattern/DateConverter.java Tue Oct 28 17:54:42 2008 @@ -62,6 +62,9 @@ return timesmapStr; } else { lastTimestamp = timestamp; + // SimpleDateFormat is not thread safe. However, since + // the AppenderBase.doAppend is synchronized, we are should be + // OK. See also http://jira.qos.ch/browse/LBCLASSIC-36 timesmapStr = simpleFormat.format(new Date(timestamp)); return timesmapStr; }

1 0

[JIRA] Reopened: (LBCLASSIC-36) Synchronization of SimpleDateFormat object in DateConverter
by Ceki Gulcu (JIRA) 28 Oct '08

28 Oct '08

[ http://jira.qos.ch/browse/LBCLASSIC-36?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu reopened LBCLASSIC-36: --------------------------------- Assignee: Ceki Gulcu (was: Logback dev list) Ralph, Are you sure SimpleDateFormat is still horribly slow? I believe that it has been significantly improved in more recent JDKs. As for moving to Joda time, I'll wait for JSR-310 to finalize. > Synchronization of SimpleDateFormat object in DateConverter > ----------------------------------------------------------- > > Key: LBCLASSIC-36 > URL: http://jira.qos.ch/browse/LBCLASSIC-36 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Anders Hammar > Assignee: Ceki Gulcu > Attachments: DateConverter_patch.java > > > According to the API documentation of SimpleDateFormat, date formats are not synchronized and it is recommended to create separate format instances for each thread. > However, a possibly simpler (mer efficient) solution would be to synchronize on the SimpleDateFormat object in the convert() method to prevent two threads to access it concurrently. -- 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] Closed: (LBCORE-39) StopWatchTest fails in Germany.
by Ceki Gulcu (JIRA) 28 Oct '08

28 Oct '08

[ http://jira.qos.ch/browse/LBCORE-39?page=com.atlassian.jira.plugin.system.i… ] Ceki Gulcu closed LBCORE-39. ---------------------------- OK. Thank you. > StopWatchTest fails in Germany. > ------------------------------- > > Key: LBCORE-39 > URL: http://jira.qos.ch/browse/LBCORE-39 > Project: logback-core > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Joern Huxhorn > Assignee: Logback dev list > Attachments: StopWatchTestPatch.patch > > > StopWatchTest must also use a DecimalFormat to check the 6.000 seconds. DecimalFormat is using DecimalFormatSymbols(Locale.getDefault()) by default so the string contained is "6,000 seconds." in Germany. -- 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-75) Synchronization of SimpleDateFormat object in DateConverter
by Ralph Goers (JIRA) 28 Oct '08

28 Oct '08

Synchronization of SimpleDateFormat object in DateConverter ----------------------------------------------------------- Key: LBCLASSIC-75 URL: http://jira.qos.ch/browse/LBCLASSIC-75 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: unspecified Environment: Operating System: All Platform: All Reporter: Ralph Goers Assignee: Logback dev list According to the API documentation of SimpleDateFormat, date formats are not synchronized and it is recommended to create separate format instances for each thread. However, a possibly simpler (mer efficient) solution would be to synchronize on the SimpleDateFormat object in the convert() method to prevent two threads to access it concurrently. -- 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] Commented: (LBCORE-39) StopWatchTest fails in Germany.
by Joern Huxhorn (JIRA) 28 Oct '08

28 Oct '08

[ http://jira.qos.ch/browse/LBCORE-39?page=com.atlassian.jira.plugin.system.i… ] Joern Huxhorn commented on LBCORE-39: ------------------------------------- I could build the latest slf4j-trunk so the problem seems to be gone. > StopWatchTest fails in Germany. > ------------------------------- > > Key: LBCORE-39 > URL: http://jira.qos.ch/browse/LBCORE-39 > Project: logback-core > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Joern Huxhorn > Assignee: Logback dev list > Attachments: StopWatchTestPatch.patch > > > StopWatchTest must also use a DecimalFormat to check the 6.000 seconds. DecimalFormat is using DecimalFormatSymbols(Locale.getDefault()) by default so the string contained is "6,000 seconds." in Germany. -- 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] Closed: (LBCORE-1) Appender interface managing Layouts?
by Ceki Gulcu (JIRA) 28 Oct '08

28 Oct '08

[ http://jira.qos.ch/browse/LBCORE-1?page=com.atlassian.jira.plugin.system.is… ] Ceki Gulcu closed LBCORE-1. --------------------------- > Appender interface managing Layouts? > ------------------------------------ > > Key: LBCORE-1 > URL: http://jira.qos.ch/browse/LBCORE-1 > Project: logback-core > Issue Type: Bug > Components: Appender > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Sébastien Pennec > Assignee: Logback dev list > Fix For: unspecified > > > Why does the c.p.l.core.Appender interface includes a getter and a setter for Layout? -- 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