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

svn commit: r1885 - in logback/trunk: . logback-access logback-classic
by noreply.ceki＠qos.ch 28 Oct '08

28 Oct '08

Author: ceki Date: Tue Oct 28 10:51:23 2008 New Revision: 1885 Modified: logback/trunk/logback-access/pom.xml logback/trunk/logback-classic/pom.xml logback/trunk/pom.xml Log: Fixing http://jira.codehaus.org/browse/MNG-2045 as suggested by Joerg Schaible. Given dependencies on test-jar logback could not be build as 'mvn package' from a pristine local repository. One had to 'mvn install' first. Modified: logback/trunk/logback-access/pom.xml ============================================================================== --- logback/trunk/logback-access/pom.xml (original) +++ logback/trunk/logback-access/pom.xml Tue Oct 28 10:51:23 2008 @@ -43,7 +43,7 @@ <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> - <classifier>tests</classifier> + <type>test-jar</type> <scope>test</scope> </dependency> Modified: logback/trunk/logback-classic/pom.xml ============================================================================== --- logback/trunk/logback-classic/pom.xml (original) +++ logback/trunk/logback-classic/pom.xml Tue Oct 28 10:51:23 2008 @@ -48,7 +48,7 @@ <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> - <classifier>tests</classifier> + <type>test-jar</type> <version>${slf4j.version}</version> <scope>test</scope> </dependency> @@ -89,7 +89,7 @@ <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> - <classifier>tests</classifier> + <type>test-jar</type> <scope>test</scope> </dependency> Modified: logback/trunk/pom.xml ============================================================================== --- logback/trunk/pom.xml (original) +++ logback/trunk/pom.xml Tue Oct 28 10:51:23 2008 @@ -54,7 +54,7 @@ <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> <version>${project.version}</version> - <classifier>tests</classifier> + <type>test-jar</type> </dependency> <dependency>

1 0

Please review and apply patches.
by Ralph Goers 28 Oct '08

28 Oct '08

I would greatly appreciate if you could review and apply the patches I provided for LBCLASSIC-35 and LBCORE-58. I need to fix a problem for a product we are deploying to production and would like to use a snapshot of Logback instead of having to create my own copy of Logback in our source control. Also, I submitted a patch for LBCLASSIC-53 some time ago to allow onMatch and onMismatch to be configured in the DynamicThresholdFilter. This isn't as big a deal except I keep noticing that my sandbox isn't in synch with trunk. Ralph

2 2

[JIRA] Commented: (LBCORE-46) DynamicClassLoadingException trying to use customAppender
by Ceki Gulcu (JIRA) 27 Oct '08

27 Oct '08

[ http://jira.qos.ch/browse/LBCORE-46?page=com.atlassian.jira.plugin.system.i… ] Ceki Gulcu commented on LBCORE-46: ---------------------------------- Hello Mark, The problem is caused by : java.lang.ClassNotFoundException: com.ziesemer.test.TestAppender As I understand it, the class loader for your WAR is a child of the EAR class loader. However, logback will attempts to use the same class loader that loaded the LoggingContext, i.e. the EAR class laoder, which cannot see com.ziesemer.test.TestAppender in your war file. Placing com.ziesemer.test.TestAppender in the EAR will solve the problem. You should also place logback.xml in the EAR file. The above should work as long as you have only one WAR file in the EAR. > DynamicClassLoadingException trying to use customAppender > --------------------------------------------------------- > > Key: LBCORE-46 > URL: http://jira.qos.ch/browse/LBCORE-46 > Project: logback-core > Issue Type: Bug > Components: Joran > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Mark A. Ziesemer > Assignee: Logback dev list > Attachments: LogBackCNFE.txt > > > I'm trying to use a custom Appender with Logback under a WebSphere 6.1 > application, but am failing upon Logback configuration with a > ch.qos.logback.core.util.DynamicClassLoadingException, caused by a > java.lang.ClassNotFoundException . > A search on this mailing list for "DynamicClassLoadingException" returned 0 > results, and neither the documentation nor Google were of any further help. > Here's my setup: > EAR: > - logback-classic-0.9.9.jar > - logback-core-0.9.9.jar > - slf4j-api-1.5.0.jar > - ... > WAR (configured to PARENT_LAST): > - logback.xml > - com.ziesemer.test.TestAppender > I will attach the stack trace / STDOUT, as it is a bit lengthy (141 lines). -- 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) 27 Oct '08

27 Oct '08

[ http://jira.qos.ch/browse/LBCLASSIC-46?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu commented on LBCLASSIC-46: ------------------------------------- ThrowableInformation was largely refactored and renamed as ThrowableProxy. Do you still needs to structure ThrowableInformation (aks ThrowableProxy) recursively? I don't understand why you would care about structure of the ThrowableInformation in Lilith. Could you please shed a some light? > 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] Created: (LBCLASSIC-76) Allow extension of LoggingEvent with new data
by Ceki Gulcu (JIRA) 27 Oct '08

27 Oct '08

Allow extension of LoggingEvent with new data ---------------------------------------------- Key: LBCLASSIC-76 URL: http://jira.qos.ch/browse/LBCLASSIC-76 Project: logback-classic Issue Type: New Feature Affects Versions: 0.9.10 Reporter: Ceki Gulcu Assignee: Ceki Gulcu Fix For: 0.9.11 Let developers add extensions to LoggingEvent. For example, if a developer wanted to have their own implementation of MDC, say XMDC, they have no elegant way of adding it to LoggingEvent. -- 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 1

[JIRA] Resolved: (LBCORE-49) LogbackMDCAdapter allocates new HashMap for every MDC call
by Ceki Gulcu (JIRA) 27 Oct '08

27 Oct '08

[ http://jira.qos.ch/browse/LBCORE-49?page=com.atlassian.jira.plugin.system.i… ] Ceki Gulcu resolved LBCORE-49. ------------------------------ Fix Version/s: unspecified Resolution: Won't Fix Matt, I do not wish to change the code to support special use cases, especially because I think it would be easy to implement an alternative MDC implementation without the "copy on modify" behavior, say XMDC. Once you have written XMDC, you would also need an XMDCConverter. Assuming that you do not wish to serialize XMDC values in the LoggingEvent, those would be the only two required additions, i.e. approx. 1 hour of work. You could add XMDC values to LoggingEvent by modifying its argument array. For example, if you converted the XMDC key/value pairs into strings, adding them to the event's argument array would have them serialized in the event. Anyway, if you wish to pursue this venue, we could work on a more elegant way on extending the LoggingEvent object. Please create a new issue if extending LoggingEvent is a path you would wish to explore. > LogbackMDCAdapter allocates new HashMap for every MDC call > ---------------------------------------------------------- > > Key: LBCORE-49 > URL: http://jira.qos.ch/browse/LBCORE-49 > Project: logback-core > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Matt Finn > Assignee: Logback dev list > Fix For: unspecified > > Attachments: mdc-diff.txt > > > A new HashMap is allocated in logback's MDC implementation for every call to MDC.put and MDC.remove. > This can lead to excessive garbage collector load in performance critical code that makes very frequent use of MDC, such as asynchronous network and file IO code. > For certain programs it is critical to have MDC capability in code hotspots, where MDC is a valuable debugging tool as applied to TRACE and DEBUG statements. > The current implementation causes a load on the garbage collector even when logging is turned off. -- 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-54) FileAppender to support FileNamePattern option
by Chris Cheshire (JIRA) 27 Oct '08

27 Oct '08

FileAppender to support FileNamePattern option ---------------------------------------------- Key: LBCORE-54 URL: http://jira.qos.ch/browse/LBCORE-54 Project: logback-core Issue Type: Improvement Components: Appender Environment: Any Reporter: Chris Cheshire Assignee: Logback dev list It would be very useful if the base FileAppender supported the FileNamePattern option, the same as the rolling policy classes do for the RollingFileAppender. This will allow for log files to be created directly into a date based directory in the format of "logs/yyyy/MM/dd/appname.log". -- 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

[JIRA] Closed: (LBSITE-13) Logback manual refers to a not existing function in org.slf4j.MDC
by Ceki Gulcu (JIRA) 27 Oct '08

27 Oct '08

[ http://jira.qos.ch/browse/LBSITE-13?page=com.atlassian.jira.plugin.system.i… ] Ceki Gulcu closed LBSITE-13. ---------------------------- > Logback manual refers to a not existing function in org.slf4j.MDC > ----------------------------------------------------------------- > > Key: LBSITE-13 > URL: http://jira.qos.ch/browse/LBSITE-13 > Project: logback-site > Issue Type: Bug > Components: Documentation > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Michael Franz > Assignee: Logback dev list > Fix For: 0.9.10 > > > The logback manual chapter 7 says: > package org.slf4j; > public class MDC { > ... > //Returns the keys in the MDC as a Set. The returned value can be null. > public static Set<String> getKeys(); > } > But the method getKeys() is not part of the released slf4j API (versions 1.4.3 and 1.5.0). > This method exists only within the LogbackMDCAdapter. -- 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: r1884 - in logback/trunk: . logback-access logback-classic logback-core logback-examples logback-site
by noreply.ceki＠qos.ch 27 Oct '08

27 Oct '08

Author: ceki Date: Mon Oct 27 21:58:07 2008 New Revision: 1884 Modified: logback/trunk/logback-access/pom.xml logback/trunk/logback-classic/pom.xml logback/trunk/logback-core/pom.xml logback/trunk/logback-examples/pom.xml logback/trunk/logback-site/pom.xml logback/trunk/pom.xml Log: 11 comes after 10 Modified: logback/trunk/logback-access/pom.xml ============================================================================== --- logback/trunk/logback-access/pom.xml (original) +++ logback/trunk/logback-access/pom.xml Mon Oct 27 21:58:07 2008 @@ -5,7 +5,7 @@ <parent> <groupId>ch.qos.logback</groupId> <artifactId>logback-parent</artifactId> - <version>0.9.10</version> + <version>0.9.11-SNAPSHOT</version> </parent> <modelVersion>4.0.0</modelVersion> Modified: logback/trunk/logback-classic/pom.xml ============================================================================== --- logback/trunk/logback-classic/pom.xml (original) +++ logback/trunk/logback-classic/pom.xml Mon Oct 27 21:58:07 2008 @@ -5,7 +5,7 @@ <parent> <groupId>ch.qos.logback</groupId> <artifactId>logback-parent</artifactId> - <version>0.9.10</version> + <version>0.9.11-SNAPSHOT</version> </parent> <modelVersion>4.0.0</modelVersion> Modified: logback/trunk/logback-core/pom.xml ============================================================================== --- logback/trunk/logback-core/pom.xml (original) +++ logback/trunk/logback-core/pom.xml Mon Oct 27 21:58:07 2008 @@ -5,7 +5,7 @@ <parent> <groupId>ch.qos.logback</groupId> <artifactId>logback-parent</artifactId> - <version>0.9.10</version> + <version>0.9.11-SNAPSHOT</version> </parent> <modelVersion>4.0.0</modelVersion> Modified: logback/trunk/logback-examples/pom.xml ============================================================================== --- logback/trunk/logback-examples/pom.xml (original) +++ logback/trunk/logback-examples/pom.xml Mon Oct 27 21:58:07 2008 @@ -5,7 +5,7 @@ <parent> <groupId>ch.qos.logback</groupId> <artifactId>logback-parent</artifactId> - <version>0.9.10</version> + <version>0.9.11-SNAPSHOT</version> </parent> <modelVersion>4.0.0</modelVersion> Modified: logback/trunk/logback-site/pom.xml ============================================================================== --- logback/trunk/logback-site/pom.xml (original) +++ logback/trunk/logback-site/pom.xml Mon Oct 27 21:58:07 2008 @@ -3,7 +3,7 @@ <parent> <groupId>ch.qos.logback</groupId> <artifactId>logback-parent</artifactId> - <version>0.9.10</version> + <version>0.9.11-SNAPSHOT</version> </parent> <modelVersion>4.0.0</modelVersion> Modified: logback/trunk/pom.xml ============================================================================== --- logback/trunk/pom.xml (original) +++ logback/trunk/pom.xml Mon Oct 27 21:58:07 2008 @@ -5,7 +5,7 @@ <groupId>ch.qos.logback</groupId> <artifactId>logback-parent</artifactId> - <version>0.9.10</version> + <version>0.9.11-SNAPSHOT</version> <packaging>pom</packaging> <name>Logback-Parent</name>

1 0

svn commit: r1883 - logback/tags/release_0.9.10/trunk
by noreply.ceki＠qos.ch 27 Oct '08

27 Oct '08

Author: ceki Date: Mon Oct 27 21:57:25 2008 New Revision: 1883 Added: logback/tags/release_0.9.10/trunk/ - copied from r1882, /logback/trunk/ Log: tagging 0.9.10

1 0