September 2011 - slf4j-dev - mailman3.qos.ch

[Bug 31] Varargs for Logger methods
by bugzilla-daemon＠pixie.qos.ch 07 Sep '11

07 Sep '11

http://bugzilla.slf4j.org/show_bug.cgi?id=31 Ceki Gulcu <listid(a)qos.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |listid(a)qos.ch --- Comment #91 from Ceki Gulcu <listid(a)qos.ch> 2011-09-07 15:57:36 CEST --- Fixing common functionality in an abstract class can alleviate some of the compatibility issues. The idea of reducing adapter implementations to two simple methods is quite brilliant. Nevertheless, Joern makes good points regarding early formatting. Message parameters must reach the logging backend unchanged whenever the backend has the appropriate hooks, e.g. logback. I am guessing that the idea of reducing adapter implementation can still be achieved albeit with different method signatures. Now imagine the following thought experiment. Assume that come up with some code structure which reduces adapter implementations two a handful of methods for all backends. At a later stage, assume we wish to enhance the org.slf4j.Logger interface with new functionality, say support for Joern's Message objects. The aforementioned methods would need to be modified to support Message objects breaking compatibility with existing adapter implementations. I see 3 possibilities to dealing with changes in SLF4J: 0) disallow any meaningful changes to SLF4J 1) allow for breaking compatibility for adapter implementations (as done historically in SLF4J) 2) come up with an abstraction so flexible that it is future proof for the next 10 years. 0 and 1 are doable. 2 requires great foresight. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 31] Varargs for Logger methods
by bugzilla-daemon＠pixie.qos.ch 07 Sep '11

07 Sep '11

http://bugzilla.slf4j.org/show_bug.cgi?id=31 --- Comment #90 from Joern Huxhorn <joern(a)huxhorn.de> 2011-09-07 11:32:28 CEST --- (In reply to comment #89) > A new proposal (and code): > > 1. Release 2.0 targeting Java 5 Agreed, but it must be possible to use 1.6.x and 2.0 side-by-side. > Those stuck on 1.4 aren't looking for the latest and greatest features. > SLF4J 1.6.2 should be sufficient. > > > 2. Add varargs with Google Collections/Guava style methods > > log*(String format, String arg1, ..., String arg6) > log*(String format, String arg1, ..., String arg6, String... others) > > There is a performance penalty for creating the implicit array required for > varargs. A quick benchmark shows this to be about 1 nanosecond. Small, but > why not eliminate it for nearly all use cases (6 or fewer args). As a bonus > with this approach, the existing one and two arg methods will fit in naturally > with this style API. The log*(format, Object[] arg) methods should be retained > for compatibility. > > This will require many new methods, but it is not as bad as it sounds. See > below. I can't help but feel dirty defining an interface like this... Even taking into account the PDF linked in comment #82, I think "optimizing" an interface like this is pretty much premature optimization. "Premature" since the next JVM (which is constantly enhanced and optimized) could suddenly implement optimizations that could result in nearly identical or even same/better performance. You can never get rid of those additional methods, ever, without having this very same discussion and having another compatibility break. I'm aware that this is a rather purist point of view but I also think that I have some very valid points... > 4. Simplify the logger adapter contract > > It seems that compatibility challenges may be largely due to the front end API > (used by application writers) is tightly bound to the adapter API (used by > logging platform developers). > > The minimum set of methods required for an adapter is two (three if > LocationAwareLogger is implemented): > > protected abstract boolean isEnabled(Marker marker, Level level); > protected abstract void log(Marker marker, Level level, String msg, Throwable > t); All maybeLog(...)-methods in NamedLoggerBase are calling the same private void log(Marker marker, Level level, String msg, Throwable t) method, already formatting the message and dropping any info about the argument array and message pattern that was used to call it. This is rather bad for several reasons: - not every logging framework/appender requires the rather expensive formatting to take place at this point or at all. Both my Logback SocketAppender and Encoder are using the raw message pattern and the arguments transformed into String instead of the formatted message. This reduces the amount of time required during the actual logging and moves the formatting into the code that is used for logging event consumption, resulting in increased performance of the logged application. - We filter on the unformatted message pattern regularly since it is much more straightforward than using the formatted message and creating a potentially very complex RegEx to catch (or rather: ignore) a specific logging call. - since losing those abilities is not an option, Logback can't use NamedLoggerBase and would therefore be required to reimplement all new methods on it's own. It also wouldn't be able to extend AbstractLogger for the same reason. > An AbstractLogger class would implement all application facing API methods. > Recommending (or requiring) log adapters to extend AbstractLogger and implement > the two methods above would effectively unbind the front end and adapter APIs. > New Logger methods could be added. Formatting would no longer be handled by > adapters. Adapter lines of code and risk of bugs would be greatly reduced. The fact that (optional) formatting is happening in the adapters is not an issue but a feature. Message formatting is an implementation detail and different frameworks can handle it in different ways (e.g. postpone it as in my Logback example). > Loggers extending AbstractLogger would of course require the 2.0 API at > runtime, with the long term benefit of simplified code and future > compatibility. I see what you are trying to achieve but it won't work, at least not in the way you've implemented it right now. Please check out comment #61, comment #69, comment #78 and comment #86 I'd really like to see the Logger extended with methods that can handle arbitrary Message implementations in addition to the current messagePattern+arguments style. Something like this has been frequently requested, i.e. being able to log with arbitrary attached objects that can still be accessed in the (Logback) appender. The way to achieve this at the moment is serializing them to a String in some way, putting them into the MDC with a name known by the appender and deserializing them in the appender by parsing in that String retrieved from the MDC. This, obviously, is less than ideal concerning performance. Cheers, Joern. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 31] Varargs for Logger methods
by bugzilla-daemon＠pixie.qos.ch 07 Sep '11

07 Sep '11

http://bugzilla.slf4j.org/show_bug.cgi?id=31 John Vasileff <git(a)netcc.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |git(a)netcc.us --- Comment #89 from John Vasileff <git(a)netcc.us> 2011-09-07 02:24:54 CEST --- A new proposal (and code): 1. Release 2.0 targeting Java 5 Those stuck on 1.4 aren't looking for the latest and greatest features. SLF4J 1.6.2 should be sufficient. 2. Add varargs with Google Collections/Guava style methods log*(String format, String arg1, ..., String arg6) log*(String format, String arg1, ..., String arg6, String... others) There is a performance penalty for creating the implicit array required for varargs. A quick benchmark shows this to be about 1 nanosecond. Small, but why not eliminate it for nearly all use cases (6 or fewer args). As a bonus with this approach, the existing one and two arg methods will fit in naturally with this style API. The log*(format, Object[] arg) methods should be retained for compatibility. This will require many new methods, but it is not as bad as it sounds. See below. 3. Maintain full (perpetual?) binary compatibility with legacy adapters. Implement the new methods listed above in NamedLoggerBase. All adapters extending NamedLoggerBase will automatically have these methods when deployed with the updated API. The new methods will be final, so logger and adapter implementations will never implement them. 4. Simplify the logger adapter contract It seems that compatibility challenges may be largely due to the front end API (used by application writers) is tightly bound to the adapter API (used by logging platform developers). The minimum set of methods required for an adapter is two (three if LocationAwareLogger is implemented): protected abstract boolean isEnabled(Marker marker, Level level); protected abstract void log(Marker marker, Level level, String msg, Throwable t); An AbstractLogger class would implement all application facing API methods. Recommending (or requiring) log adapters to extend AbstractLogger and implement the two methods above would effectively unbind the front end and adapter APIs. New Logger methods could be added. Formatting would no longer be handled by adapters. Adapter lines of code and risk of bugs would be greatly reduced. Loggers extending AbstractLogger would of course require the 2.0 API at runtime, with the long term benefit of simplified code and future compatibility. An initial implementation for these items is availabe at: https://github.com/jvasileff/slf4j/tree/topic-jdk5-varargs There are two commits to look at. The first covers #1, #2, and #3. The second adds #4. John -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 166] New: please add OSGI informations to jul-to-slf4j-1.5.10.jar
by bugzilla-daemon＠pixie.qos.ch 02 Sep '11

02 Sep '11

http://bugzilla.slf4j.org/show_bug.cgi?id=166 Summary: please add OSGI informations to jul-to-slf4j-1.5.10.jar Product: SLF4J Version: 1.5.x Platform: All OS/Version: Mac OS X 10.3 Status: NEW Severity: normal Priority: P3 Component: Unspecified AssignedTo: slf4j-dev(a)qos.ch ReportedBy: ekke(a)ekkes-corner.org jul-to-slf4j-1.5.10.jar MANIFEST.MF is missing OSGI Informations ... Import-Package: org.slf4j;version="1.5.10", org.slf4j.spi;version="1.5.10" Export-Package: org.slf4j.bridge;version="1.5.10" ... so you have to wrap it by yourself or as workaround use the Bundle provided by SpringSource: http://www.springsource.com/repository/app/bundle/version/detail?name=com.s… ----- thx ekke -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 4

[Bug 238] New: MDC.mdcAdapter is not thread safe.
by bugzilla-daemon＠pixie.qos.ch 01 Sep '11

01 Sep '11

http://bugzilla.slf4j.org/show_bug.cgi?id=238 Summary: MDC.mdcAdapter is not thread safe. Product: SLF4J Version: 1.6.x Platform: Macintosh OS/Version: Mac OS X 10.3 Status: NEW Severity: blocker Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: zhaotq(a)gmail.com In my tomcat environment, logback throws NullPointerException occasionally. The satack trace looks like: Exception in thread "Thread-5" java.lang.NullPointerException at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:135) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:471) at ch.qos.logback.classic.Logger.filterAndLog_2(Logger.java:464) at ch.qos.logback.classic.Logger.debug(Logger.java:542) at com.alu.ipd.ode.customer.exponentiale.reporting.ram.RamMonitor$RamServerChecker.run(RamMonitor.java:140) Look at the code of LoggingEvent.java around line 135: LogbackMDCAdapter logbackMDCAdapter = (LogbackMDCAdapter) MDC .getMDCAdapter(); mdcPropertyMap = logbackMDCAdapter.getPropertyMap(); Sometime the MDC.getMDCAdapter() returns null, which caused the NullPointerException. I did a lot of debugging, found that the exception would not happen if I watched the MDC.mdcAdapter with the debugger also found no changed to it. I believed that this must be a threading issue, and modified the MDC's static initializer as below: static final MDCAdapter mdcAdapter; static { MDCAdapter mdcAdapter1=null; try { mdcAdapter1 = StaticMDCBinder.SINGLETON.getMDCA(); } catch (NoClassDefFoundError ncde) { mdcAdapter1 = new NOPMDCAdapter(); String msg = ncde.getMessage(); if (msg != null && msg.indexOf("org/slf4j/impl/StaticMDCBinder") != -1) { Util.report("Failed to load class \"org.slf4j.impl.StaticMDCBinder\"."); Util.report("Defaulting to no-operation MDCAdapter implementation."); Util .report("See " + NO_STATIC_MDC_BINDER_URL + " for further details."); } else { throw ncde; } } catch (Exception e) { // we should never get here Util.report("MDC binding unsuccessful.", e); } finally { mdcAdapter = mdcAdapter1; } } NOTE: The key here is: make the mdcAdapter final. I used a temporary variable mdcAdapter1 and assigned it to mdcAdapter in the finally clause. After this change, the NullPointerException never happens. I used slf4j 1.6.2 and logback 0.9.29. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1