- logback-dev - mailman3.qos.ch

[JIRA] Resolved: (LBCLASSIC-56) Dealing with the '\\' during substitution
by Ceki Gulcu (JIRA) 29 Oct '08

29 Oct '08

[ http://jira.qos.ch/browse/LBCLASSIC-56?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu resolved LBCLASSIC-56. --------------------------------- Fix Version/s: 0.9.10 Resolution: Fixed resolved in revision 1706. > Dealing with the '\\' during substitution > ----------------------------------------- > > Key: LBCLASSIC-56 > URL: http://jira.qos.ch/browse/LBCLASSIC-56 > Project: logback-classic > Issue Type: Bug > Reporter: Ceki Gulcu > Assignee: Logback dev list > Fix For: 0.9.10 > > > QUOTE > I'm been unsuccessful at using the RollingFileAppender with a > FixedWindowRollingPolicy that has this FileNamePattern: > <FileNamePattern>${user.home}/Client%i.log</FileNamePattern> > "${user.home}/Client%i.log" gets correctly expanded to "C:\\Documents and > Settings\\Michel/Client%i.log" when it's passed to the > FixedWindowRollingPolicy constructor. > The problem starts once the filename gets parsed by > ch.qos.logback.core.pattern.parser.Parser: the filename becomes "C:ocuments > and Settingsichel/Client". > File rotations then fails (as would be expected) when trying to rename the > current log to "C:ocuments and Settingsichel/Client1.log" > Is there a way to configure logback to correctly deal with the "\\" used in > windows? > End of quote > For original report see: http://www.qos.ch/pipermail/logback-user/2008-June/000476.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 0

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

29 Oct '08

[ http://jira.qos.ch/browse/LBCLASSIC-46?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu commented on LBCLASSIC-46: ------------------------------------- The 'x commons framed omitted' helps to significantly reduce the number of printed stack lines for nested exceptions. However, I don't think the nested ThrowableProxy structure you propose precludes the calculation of commons frames. > 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: Ceki Gulcu > 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: r1900 - logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi
by noreply.ceki＠qos.ch 29 Oct '08

29 Oct '08

Author: ceki Date: Wed Oct 29 12:05:04 2008 New Revision: 1900 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/StackTraceElementProxy.java Log: related to LBCLASSIC-72 In StackTracementElement proxy, the setPackageInfo method was renamed as setClassPackagingData for consistency. The steAsString field marked as transient to save a few byte during serialization (we can reconstruct this field from 'ste') 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 29 12:05:04 2008 @@ -91,11 +91,11 @@ firsExactClassLoader = callerClass.getClassLoader(); } ClassPackagingData pi = calculateByExactType(callerClass); - step.setPackageInfo(pi); + step.setClassPackagingData(pi); } else { missfireCount++; ClassPackagingData pi = computeBySTEP(step, lastExactClassLoader); - step.setPackageInfo(pi); + step.setClassPackagingData(pi); } } populateUncommonFrames(commonFrames, stepArray, firsExactClassLoader); @@ -139,7 +139,7 @@ for (int i = 0; i < uncommonFrames; i++) { StackTraceElementProxy step = stepArray[i]; ClassPackagingData pi = computeBySTEP(step, firstExactClassLoader); - step.setPackageInfo(pi); + step.setClassPackagingData(pi); } } Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/StackTraceElementProxy.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/StackTraceElementProxy.java (original) +++ logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/StackTraceElementProxy.java Wed Oct 29 12:05:04 2008 @@ -7,7 +7,9 @@ private static final long serialVersionUID = -4832130320500439038L; final StackTraceElement ste; - private String steAsString; + // save a byte or two during serialization, as we can + // reconstruct this field from 'ste' + transient private String steAsString; private ClassPackagingData cpd; StackTraceElementProxy(StackTraceElement ste) { @@ -29,7 +31,7 @@ return ste; } - void setPackageInfo(ClassPackagingData cpd) { + void setClassPackagingData(ClassPackagingData cpd) { this.cpd = cpd; }

1 0

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

29 Oct '08

Author: ceki Date: Wed Oct 29 11:21:49 2008 New Revision: 1899 Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/StackTraceElementProxy.java Log: added a getter for 'ste' as requested in LBCLASSIC-72 Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/StackTraceElementProxy.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/StackTraceElementProxy.java (original) +++ logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/StackTraceElementProxy.java Wed Oct 29 11:21:49 2008 @@ -17,13 +17,18 @@ this.ste = ste; } + public String getSTEAsString() { if (steAsString == null) { steAsString = "\tat " + ste.toString(); } return steAsString; } - + + public StackTraceElement getStackTraceElement() { + return ste; + } + void setPackageInfo(ClassPackagingData cpd) { this.cpd = cpd; }

1 0

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

29 Oct '08

Author: ceki Date: Wed Oct 29 11:16:00 2008 New Revision: 1898 Modified: logback/trunk/logback-site/src/site/pages/faq.html Log: - removing questions which are best answered in SLF4J - added an entry about logger deserialization (related to LBCLASSIC-74 ) Modified: logback/trunk/logback-site/src/site/pages/faq.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/faq.html (original) +++ logback/trunk/logback-site/src/site/pages/faq.html Wed Oct 29 11:16:00 2008 @@ -32,35 +32,36 @@ <h3>Logback Classic</h3> - <ol type="1"> + <ol type="1"> <li> - <a href="#setup_jetty"> - How can I use logback-classic with Jetty ? - </a> - </li> - <li> - <a href="#auto_config"> - How does the automatic configuration work? - </a> - </li> + <a href="#logger_serialization">Are logback loggers + serializable?</a> + </li> + <li> - <a href="#intercept_calls_tomcat"> - How can I intercept JCL calls in Tomcat? - </a> - </li> + <a href="#auto_config">How does the automatic configuration + work?</a> + </li> <li> - <a href="#intercept_calls_jetty"> - How can I intercept JCL calls in Jetty ? + <a href="#setup_jetty">How can Jetty be instructed to use + logback-classic as its logging implementataion? </a> </li> </ol> + +  +  +  +  + <div class="section"> <h2>Logback project</h2> <dl> - <dt> <a name="why_lgpl">Why is logback distributed under LGPL and - not the Apache Software License?</a> + <dt> + <a name="why_lgpl" href="#why_lgpl">Why is logback distributed + under LGPL and not the Apache Software License?</a> </dt> <dd> @@ -79,22 +80,66 @@ </dd> </dl> </div> + <div class="section"> <h2>Logback-classic</h2> <dl> + +  + + <dt> + <a name="auto_config" href="#auto_config"> + How does the automatic configuration work? + </a> + </dt> + <dd> + This question is answered in the <a + href="manual/joran.html#auto_configuration">relevant + section</a> of the logback manual. + + + </dd> + + <hr/> + +  + + + + <dt> + <a name="logger_serialization" href="#logger_serialization"> + Are logback loggers serializable?</a> + </dt> + <dd> + Yes. A logback logger is an SLF4J logger and SLF4J + loggers are serializable. This means that an object + referencing a logger will be alble to log after its + deserialization. + + + The deserialized logger instance will be generated by + <code>org.slf4j.LoggerFactory</code>. Thus, it is possible + for a logback logger to be deserialized as a log4j or j.u.l. + logger, depending on the deserialization environment. + </dd> + + <hr/> +  + <dt> - <a name="setup_jetty"> - How can I use logback-classic with Jetty ? + <a name="setup_jetty" href="#"> + How can Jetty be instructed to use logback-classic as its + logging implementataion? </a> </dt> + <dd> The Jetty application server uses SLF4J for its internal - logging. Here are the required steps to install logback as - SLF4J's underlaying implementation. + logging. - A few jars must be present in the JETTY_HOME/lib - directory. + The following jar files must be present in the + JETTY_HOME/lib directory. Logback-classic is based on the SLF4J api. Therefore, the @@ -109,117 +154,21 @@ To configure logback-classic, a file called logback.xml should be placed in the - JETTY_HOME/resources directory. You can find - configuration samples in the - examples/src/chapter4/conf/ directory, in the - distribution of logback. + JETTY_HOME/resources directory. You can find sample + configuration files in the + logback-examples/src/main/java/chapter4/conf/ folder + shipping within the logback distribution. - <table border="0"> - <tr> - <td align="right"> - <a href="#top">[top]</a> - </td> - </tr> - </table> - <hr /> - </dd> - <dt> - <a name="auto_config"> - How does the automatic configuration work? - </a> - </dt> - <dd> - This question is answered in the <a - href="manual/joran.html#auto_configuration">relevant - section</a> of the logback manual. - - <table border="0"> - <tr> - <td align="right"> - <a href="#top">[top]</a> - </td> - </tr> - </table> - <hr /> - </dd> - <dt> - <a name="intercept_calls_tomcat"> - How can I intercept JCL calls in Tomcat? - </a> - </dt> - <dd> - When a dependency of your webapp logs using Jakarta Commons - Logging (for example Struts), you can intercept these calls - and redirect them to logback. - - This can be done by using jcl104-over-slf4j.jar , - a module that is shipped with <a - href="http://www.slf4j.org">SLF4J</a> . - - If you have only one webapp, its WEB-INF/lib - directory should already contain the logback jars, namely - logback-core-VERSION.jar , - logback-classic-VERSION.jar and - slf4j-api-VERSION.jar . A logback configuration file, - named logback.xml should be placed in the - WEB-INF/classes/ directory. - - You now need to add <code>jcl104-over-slf4j.jar</code> to - your WEB-INF/lib directory and remove - <code>commons-logging-1.0.4.jar</code> . The logging that used - to be directed to JCL should now be handled by logback. - - - In case several webapps share the logback jars, you might - place the previously mentionned jars in the - common/lib/ directory of your Tomcat - installation. The logback.xml file should then be - placed in common/classes . - - <table border="0"> - <tr> - <td align="right"> - <a href="#top">[top]</a> - </td> - </tr> - </table> - <hr /> - </dd> - <dt> - <a name="intercept_calls_jetty"> - How can I intercept JCL calls in Jetty ? - </a> - </dt> - <dd> - Using logback as the logging implementation of choice for - frameworks depending on JCL can also be done in Jetty. - - In case you have only one webapp, the required steps are - exactly the same as <a href="#intercept_calls_tomcat">those - needed in Tomcat</a>. - - In case several webapps share the logback jars, you might - place the necessary jars in the lib/ directory of - your Jetty installation. The logback.xml file should - then be placed in the resources/ directory. - - However, due to <a - href="http://docs.codehaus.org/display/JETTY/Classloading"> - Jetty's internal Classloading mechanism</a>, the - logback-classic-VERSION.jar and - slf4j-api-VERSION.jar files should also be placed in - the WEB-INF/lib/ directory of your webapps. - - <table border="0"> - <tr> - <td align="right"> - <a href="#top">[top]</a> - </td> - </tr> - </table> </dd> + + <hr /> + + +  </dl> + + </div> </div>

1 0

[JIRA] Issue Comment Edited: (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 edited comment on LBCLASSIC-46 at 10/29/08 11:06 AM: ------------------------------------------------------------------- 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(), see also LBCLASSIC-45 ) when needed instead of, like it is right now, during creation of the logging event itself. It's also leaner in case of serialization. was (Author: jhuxhorn): 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) 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