- logback-dev - mailman3.qos.ch

svn commit: r1702 - logback/trunk/logback-site/src/site/resources
by noreply.ceki＠qos.ch 03 Jun '08

03 Jun '08

Author: ceki Date: Tue Jun 3 17:48:23 2008 New Revision: 1702 Modified: logback/trunk/logback-site/src/site/resources/10reasons.ppt Log: - slightly improved version of the slides Modified: logback/trunk/logback-site/src/site/resources/10reasons.ppt ============================================================================== Binary files. No diff available.

1 0

[JIRA] Commented: (LBCLASSIC-45) Suggestion: Make LoggingEvent dumber, Logger more intelligent
by Joern Huxhorn (JIRA) 02 Jun '08

02 Jun '08

[ http://jira.qos.ch/browse/LBCLASSIC-45?page=com.atlassian.jira.plugin.syste… ] Joern Huxhorn commented on LBCLASSIC-45: ---------------------------------------- This might be true, depending on how the functionality in question would be implemented. I agree with you that always extracting the caller data wouldn't be an option at all - even though I must admit that I leave this option on, even in production systems, since performance is still quite acceptable ;) I'd suggest to configure globally if caller data and/or thread name should be extracted for LoggingEvents instead of on a per appender option. This would mean that caller data would be extracted in the Logger (instead of in LoggingEvent) if requested by the configuration. Beside solving the problem you mentioned (e.g. passing LoggingEvent to another Thread without calling getCallerData first) it would also simplify Logger, LoggingEvent and Appenders, reducing the chance of potential problems, like forgetting to call prepareForDeferredProcessing()/getThreadName() or getCallerData in appenders even though it would be needed. Another, more or less similar, point is the lazy initialization of threadName. It has the same problem, i.e. it mustn't be called on a different thread for the first time, and does have a performance impact. One of my original points of this RFE was to remove potential pitfalls related to IMO unnecessary complexity in LoggingEvent. While performance is obviously the most important aspect of LoggingEvent creation (which isn't optimal at the moment because of eager creation of formatted message in c'tor), ease and simplicity of use should be a close second ;) So what's the general opinion on a globally configured ExtractCallerData and Extract/ResolveThreadName? > Suggestion: Make LoggingEvent dumber, Logger more intelligent > ------------------------------------------------------------- > > Key: LBCLASSIC-45 > URL: http://jira.qos.ch/browse/LBCLASSIC-45 > 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 > > This change would introduce incompatibilities with previous versions but would increase general logging performance and decrease size of serialized events. > After I have turned you off sufficiently ;), let me explain my idea: > At the moment, LoggingEvent is handling it's own initialization. It even contains measures against manipulation after initialization in that a call of a setter results in an IllegalStateException if the attribute has already been initialized before. > Instead, I'd suggest that LoggingEvent is changed into a dumb data container with getter and setters for all it's attributes. > If it's really necessary to have a semi-const LoggingEvent I'd suggest to define LoggingEvent as an interface containing only the getters of the attributes and an implementation LoggingEventImpl that implements LoggingEvent including getters and setters. > This communicates the *intent* that LoggingEvents aren't supposed to be modified but nothing more. It would still be possible to change e.g. the content of an array like argumentArray. Even if the getter would return a copy of the contained array, generating heat in the process, it would *still* be possible to brutally manipulate the LoggingEvent using java.lang.reflection setAccessible(true) so it's just not possible to guarantee constness. > Instead of having a pseudo-const LoggingEvent let's dump the constness altogether and make it a dumb data container that contains no logic at all. This would instead be moved to the Logger class. > I'd also suggest to remove formattedMessage and change the argumentArray to String[]. > This is possible because logback-classic/slf4j promises formatted message, not LoggingEvent. > It would increase performance because a Logger would simply create a LoggingEvent without performing a possibly unnecessary formatting of the message. Creation of LoggingEvents should be as fast and simple as possible, obviously. > The formatting of the message should/would instead be performed in the appender (or, more generally, user of the event) if required. > A serializing appender, an xml appender (e.g. using java.beans.XMLEncoder) or a socket appender would *not* require a formatted message, executing significantly faster than before. > The argumentArray should be String[] to securely prevent java.io.NotSerializableException in the serializer and . java.lang.ClassNotFoundException in the deserializer. > LoggerRemoteView and LoggerContextRemoteView should be changed the same way as LoggingEvent, i.e. just data container, logic moved to Logger, for similar reasons. > I have to admit, though, that I currently don't understand the reason the LoggingEvent needs to know about LoggerContext beside resolving of the Logger name. I couldn't find code that uses LoggerContextRemoteView.getPropertyMap(), beside loading and saving it. > So I think it may be possible that LoggerRemoteView isn't really necessary and could be removed from LoggingEvent... remembering the Logger name instead. > fqnOfLoggerClass could be omitted because the CallerData would be created in the Logger where fqnOfLoggerClass is known. > And last but not least I'd also change Level into an java.lang.Enum. > I don't expect that all this will be done but I wanted to suggest it nevertheless because it would both increase performance and produce cleaner code. > Breaking compatibility would IMHO be worth it - after all, logback isn't 1.0, yet ;) > If you are interested I'd volunteer to implement those changes, after signing http://logback.qos.ch/cla.txt of course. > Keywords: > Inversion of Control (IoC), separation of concerns, KISS principle > Related bugs: > http://bugzilla.qos.ch/show_bug.cgi?id=100 > http://bugzilla.qos.ch/show_bug.cgi?id=118 > http://bugzilla.slf4j.org/show_bug.cgi?id=70 -- 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-45) Suggestion: Make LoggingEvent dumber, Logger more intelligent
by Ralph Goers (JIRA) 01 Jun '08

01 Jun '08

[ http://jira.qos.ch/browse/LBCLASSIC-45?page=com.atlassian.jira.plugin.syste… ] Ralph Goers commented on LBCLASSIC-45: -------------------------------------- CallerData isn't normally resolved until something wants it. This is done presumably for performance reasons. The change you suggest could potentially make logging much slower (although I haven't benchmarked it). However, the way it is currently implemented, if the LoggingEvent was passed to another thread for asynchronous processing calling getCallerData() there would yield incorrect results. > Suggestion: Make LoggingEvent dumber, Logger more intelligent > ------------------------------------------------------------- > > Key: LBCLASSIC-45 > URL: http://jira.qos.ch/browse/LBCLASSIC-45 > 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 > > This change would introduce incompatibilities with previous versions but would increase general logging performance and decrease size of serialized events. > After I have turned you off sufficiently ;), let me explain my idea: > At the moment, LoggingEvent is handling it's own initialization. It even contains measures against manipulation after initialization in that a call of a setter results in an IllegalStateException if the attribute has already been initialized before. > Instead, I'd suggest that LoggingEvent is changed into a dumb data container with getter and setters for all it's attributes. > If it's really necessary to have a semi-const LoggingEvent I'd suggest to define LoggingEvent as an interface containing only the getters of the attributes and an implementation LoggingEventImpl that implements LoggingEvent including getters and setters. > This communicates the *intent* that LoggingEvents aren't supposed to be modified but nothing more. It would still be possible to change e.g. the content of an array like argumentArray. Even if the getter would return a copy of the contained array, generating heat in the process, it would *still* be possible to brutally manipulate the LoggingEvent using java.lang.reflection setAccessible(true) so it's just not possible to guarantee constness. > Instead of having a pseudo-const LoggingEvent let's dump the constness altogether and make it a dumb data container that contains no logic at all. This would instead be moved to the Logger class. > I'd also suggest to remove formattedMessage and change the argumentArray to String[]. > This is possible because logback-classic/slf4j promises formatted message, not LoggingEvent. > It would increase performance because a Logger would simply create a LoggingEvent without performing a possibly unnecessary formatting of the message. Creation of LoggingEvents should be as fast and simple as possible, obviously. > The formatting of the message should/would instead be performed in the appender (or, more generally, user of the event) if required. > A serializing appender, an xml appender (e.g. using java.beans.XMLEncoder) or a socket appender would *not* require a formatted message, executing significantly faster than before. > The argumentArray should be String[] to securely prevent java.io.NotSerializableException in the serializer and . java.lang.ClassNotFoundException in the deserializer. > LoggerRemoteView and LoggerContextRemoteView should be changed the same way as LoggingEvent, i.e. just data container, logic moved to Logger, for similar reasons. > I have to admit, though, that I currently don't understand the reason the LoggingEvent needs to know about LoggerContext beside resolving of the Logger name. I couldn't find code that uses LoggerContextRemoteView.getPropertyMap(), beside loading and saving it. > So I think it may be possible that LoggerRemoteView isn't really necessary and could be removed from LoggingEvent... remembering the Logger name instead. > fqnOfLoggerClass could be omitted because the CallerData would be created in the Logger where fqnOfLoggerClass is known. > And last but not least I'd also change Level into an java.lang.Enum. > I don't expect that all this will be done but I wanted to suggest it nevertheless because it would both increase performance and produce cleaner code. > Breaking compatibility would IMHO be worth it - after all, logback isn't 1.0, yet ;) > If you are interested I'd volunteer to implement those changes, after signing http://logback.qos.ch/cla.txt of course. > Keywords: > Inversion of Control (IoC), separation of concerns, KISS principle > Related bugs: > http://bugzilla.qos.ch/show_bug.cgi?id=100 > http://bugzilla.qos.ch/show_bug.cgi?id=118 > http://bugzilla.slf4j.org/show_bug.cgi?id=70 -- 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: r1701 - logback/trunk/logback-classic/src/main/java/org/slf4j/impl
by noreply.ceki＠qos.ch 27 May '08

27 May '08

Author: ceki Date: Tue May 27 22:01:26 2008 New Revision: 1701 Modified: logback/trunk/logback-classic/src/main/java/org/slf4j/impl/LogbackMDCAdapter.java Log: - getCopyOfPropertyMap was renamed as getCopyOfContextMap in SLF4J 1.5.1 Modified: logback/trunk/logback-classic/src/main/java/org/slf4j/impl/LogbackMDCAdapter.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/org/slf4j/impl/LogbackMDCAdapter.java (original) +++ logback/trunk/logback-classic/src/main/java/org/slf4j/impl/LogbackMDCAdapter.java Tue May 27 22:01:26 2008 @@ -124,7 +124,7 @@ * Return a copy of the current thread's context map. * Returned value may be null. */ - public Map getCopyOfPropertyMap() { + public Map getCopyOfContextMap() { HashMap<String, String> hashMap = inheritableThreadLocal.get(); if (hashMap == null) { return null;

1 0

svn commit: r1700 - logback/trunk/logback-classic/src/main/java/org/slf4j/impl
by noreply.ceki＠qos.ch 27 May '08

27 May '08

Author: ceki Date: Tue May 27 20:36:24 2008 New Revision: 1700 Modified: logback/trunk/logback-classic/src/main/java/org/slf4j/impl/LogbackMDCAdapter.java Log: - catching up with SLF4J 1.5.1 by adding the getCopyOfPropertyMap Modified: logback/trunk/logback-classic/src/main/java/org/slf4j/impl/LogbackMDCAdapter.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/org/slf4j/impl/LogbackMDCAdapter.java (original) +++ logback/trunk/logback-classic/src/main/java/org/slf4j/impl/LogbackMDCAdapter.java Tue May 27 20:36:24 2008 @@ -121,6 +121,20 @@ } /** + * Return a copy of the current thread's context map. + * Returned value may be null. + */ + public Map getCopyOfPropertyMap() { + HashMap<String, String> hashMap = inheritableThreadLocal.get(); + if (hashMap == null) { + return null; + } else { + return new HashMap<String, String>(hashMap); + } + } + + + /** * Returns the keys in the MDC as a {@link Set}. The returned value can be * null. */

1 0

[JIRA] Commented: (GENERAL-18) Attachments are lost during migration from bugzilla to JIRA
by JIRA Administrator (JIRA) 22 May '08

22 May '08

[ http://jira.qos.ch/browse/GENERAL-18?page=com.atlassian.jira.plugin.system.… ] JIRA Administrator commented on GENERAL-18: ------------------------------------------- Apparently, it is a well-known problem with a not-so-convenient-but-ok fix: http://confluence.atlassian.com/display/JIRA/Migrating+from+Bugzilla+3.0.3 > Attachments are lost during migration from bugzilla to JIRA > ----------------------------------------------------------- > > Key: GENERAL-18 > URL: http://jira.qos.ch/browse/GENERAL-18 > Project: logback-general > Issue Type: Bug > Components: build-structure > Affects Versions: unspecified > Reporter: Roland Klein > Assignee: Logback dev list > > The Attachments are lost during migration from bugzilla to JIRA. > e.g. bugzilla #107 -> JIRA #32 Patch is gone -- 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

[Bug 107] Specificy the config file to use as a System property
by bugzilla-daemon＠pixie.qos.ch 22 May '08

22 May '08

show_bug.cgi?id=107 Ceki Gulcu <noreply.ceki(a)qos.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |noreply.ceki(a)qos.ch --- Comment #7 from Ceki Gulcu <noreply.ceki(a)qos.ch> 2008-05-22 22:35:11 --- x -- Configure bugmail: userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[JIRA] Commented: (GENERAL-18) Attachments are lost during migration from bugzilla to JIRA
by Ceki Gulcu (JIRA) 22 May '08

22 May '08

[ http://jira.qos.ch/browse/GENERAL-18?page=com.atlassian.jira.plugin.system.… ] Ceki Gulcu commented on GENERAL-18: ----------------------------------- Hello Roland, That sounds pretty bad. I'll look into it. > Attachments are lost during migration from bugzilla to JIRA > ----------------------------------------------------------- > > Key: GENERAL-18 > URL: http://jira.qos.ch/browse/GENERAL-18 > Project: logback-general > Issue Type: Bug > Components: build-structure > Affects Versions: unspecified > Reporter: Roland Klein > Assignee: Logback dev list > > The Attachments are lost during migration from bugzilla to JIRA. > e.g. bugzilla #107 -> JIRA #32 Patch is gone -- 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

Migrated to JIRA
by Ceki Gulcu 20 May '08

20 May '08

The logback project now relies on to JIRA instead of Bugzilla as its bug tracking system. Previous bug reports as well existing users in Bugzilla have been migrated to JIRA. Thus, from now on, please use JIRA to create or edit bug reports. The url is: http://jira.qos.ch/ Let me know if you encounter any problems. -- Ceki Gülcü

1 0

svn commit: r1699 - logback/trunk/logback-site/src/site/pages
by noreply.ceki＠qos.ch 20 May '08

20 May '08

Author: ceki Date: Tue May 20 17:31:47 2008 New Revision: 1699 Modified: logback/trunk/logback-site/src/site/pages/bugreport.html Log: - migrated from bugzilla to JIRA Modified: logback/trunk/logback-site/src/site/pages/bugreport.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/bugreport.html (original) +++ logback/trunk/logback-site/src/site/pages/bugreport.html Tue May 20 17:31:47 2008 @@ -24,58 +24,68 @@ <h2>Before you report a bug</h2> -<p> -The logback community consists of those who use logback and its modules, -help answer questions on discussions lists, contribute documentation and patches, -and those who develop and maintain the code for logback and its modules. -Almost all those who assist on a day to day basis resolving bug reports do this for -a wide variety of reasons, and almost all of them do this on their own time. -</p> -<p> -Many bugs reported end up not being a bug in logback, but are due to misconfiguration, -problems caused by installed applications, the operating system, etc. -</p> -<p> -Before reporting a bug please make every effort to resolve the problem yourself. -Just reporting a bug will not fix it. A good bug report includes a detailed description -of the problem and a succinct test case which can reproduce the problem. -</p> - -<h3>Review the documentation</h3> -<p> -Review the documentation for the version of component you are using. -The problem you are having may already be addressed in the docs. -</p> - -<h3>Search the mailing list archives</h3> -<p> -It is very likely you are not the first to run into a problem. -Others may have already found a solution. -Our various mailing lists are likely to have discussed this problem before. -</p> - -<h3>Search Bugzilla</h3> - -<p> -Please search the bug database to see if the bug you are seeing has already been reported. -The bug may have already been fixed and is available in a later version. -If someone else has reported the same bug, you could add supporting information to help reproduce and resolve the bug. -</p> -<ul> - <li><a href="http://bugzilla.qos.ch/query.cgi">Search for logback bugs</a></li> -</ul> - -<h2>Reporting with Bugzilla</h2> -<p> -Only after you have exhausted the aforementioned steps, should you file a formal report in bugzilla. -</p> -<p> -Please make sure you provide as much information as possible. -Its very hard to fix a bug if the person looking into the problem can't reproduce it. -</p> -<ul> - <li><a href="http://bugzilla.qos.ch/enter_bug.cgi">Report new logback bug</a></li> -</ul> + <p>The logback community consists of those who use logback and its + modules, help answer questions on discussions lists, contribute + documentation and patches, and those who develop and maintain its + code. Almost all those who assist on a day to day basis resolving + bug reports do this for a wide variety of reasons, and almost all of + them do this on their own time.</p> + + <p>Many bugs reported end up not being a bug in logback, but are due + to misconfiguration, problems caused by installed applications, the + operating system, etc. + </p> + + <p>Before reporting a bug please make every effort to resolve the + problem yourself. Just reporting a bug will not fix it. A good bug + report includes a detailed description of the problem and a succinct + test case which can reproduce the problem. + </p> + + <h3>Review the documentation</h3> + + <p>Review the documentation for the version of component you are + using. The problem you are having may already be addressed in the + docs. + </p> + + <h3>Search the mailing list archives</h3> + + <p>It is very likely you are not the first to run into a problem. + Others may have already found a solution. Our various mailing lists + are likely to have discussed this problem before. + </p> + + <h3>Search JIRA</h3> + + <p>Please search the bug database to see if the bug you are seeing + has already been reported. The bug may have already been fixed and + is available in a later version. If someone else has reported the + same bug, you could add supporting information to help reproduce and + resolve the bug. + </p> + + <ul> + <li><a href="http://jira.qos.ch/secure/IssueNavigator.jspa">Search + for logback bugs</a></li> + </ul> + + <h2>Reporting with bugs</h2> + + <p> Only after you have exhausted the aforementioned steps, should + you file a formal report in JIRA, our bug tracking system. + </p> + + <p>Please make sure you provide as much information as possible. + Its very hard to fix a bug if the person looking into the problem + can't reproduce it. + </p> + + <ul> + <li><a + href="http://jira.qos.ch/secure/CreateIssue!default.jspa">Report + new logback bug</a></li> + </ul> <script src="templates/footer.js"></script> </div>

1 0