- 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 --- 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

[Bug 237] New: NoSuchMethodError LogManager.getLoggerRepository
by bugzilla-daemon＠pixie.qos.ch 30 Aug '11

30 Aug '11

http://bugzilla.slf4j.org/show_bug.cgi?id=237 Summary: NoSuchMethodError LogManager.getLoggerRepository Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P1 Component: log4j-over-slf4j AssignedTo: slf4j-dev(a)qos.ch ReportedBy: jasperv(a)topdesk.com I ran into a NoSuchMethodError when I incorporated a dependency which called the log4j LogManager.getLoggerRepository directly. I managed to solve it's absence by creating my own implementation of the LogManager class with a NOP getLoggerRepository method. In bug report 202 the absence of this method was also noted, but deemed invalid. Might I ask why this method will not be included in the bridge? Other NOP methods have been included so why not this one? -- 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

[GIT] SLF4J: Simple Logging Facade for Java branch, master, updated. v_1.6.2-1-g13dddd5
by git-noreply＠pixie.qos.ch 26 Aug '11

26 Aug '11

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "SLF4J: Simple Logging Facade for Java". The branch, master has been updated via 13dddd52b72ac1c3bd2971d5c30a6f66cfae47ca (commit) from 1bb6ebb8f5b63569920101f79132f525437aa964 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://git.qos.ch/gitweb/?p=slf4j.git;a=commit;h=13dddd52b72ac1c3bd2971d5c3… http://github.com/ceki/slf4j/commit/13dddd52b72ac1c3bd2971d5c30a6f66cfae47ca commit 13dddd52b72ac1c3bd2971d5c30a6f66cfae47ca Author: Ceki Gulcu <ceki(a)qos.ch> Date: Fri Aug 26 13:27:12 2011 +0200 mindor edits diff --git a/slf4j-site/src/site/pages/faq.html b/slf4j-site/src/site/pages/faq.html index dbae2c6..b226ac4 100644 --- a/slf4j-site/src/site/pages/faq.html +++ b/slf4j-site/src/site/pages/faq.html @@ -364,7 +364,8 @@ from SLF4J version 1.0 to any later version without problems. Code compiled with slf4j-api-versionN.jar will work with slf4j-api-versionM.jar for any versionN - and any versionM + and any versionM. To date, binary compatibility in slf4j-api + has never been broken. However, while the SLF4J API is very stable from the client's perspective, SLF4J bindings, e.g. slf4j-simple.jar or @@ -399,13 +400,13 @@ org.slf4j.impl.StaticLoggerBinder.SINGLETON from class org.slf4j.LoggerFactory at org.slf4j.LoggerFactory.<clinit>(LoggerFactory.java:60)</pre> - This error is caused by the static initilizer of the - <code>LoggerFactory</code> class attempting to directly access - the SINGLETON field of - <code>org.slf4j.impl.StaticLoggerBinder</code>. While this was - allowed in SLF4J 1.5.5 and earlier, in 1.5.6 and later the - SINGLETON field has been marked as private access. - + This error is caused by the static initilizer of the + <code>LoggerFactory</code> class attempting to directly access + the SINGLETON field of + <code>org.slf4j.impl.StaticLoggerBinder</code>. While this was + allowed in SLF4J 1.5.5 and earlier, in 1.5.6 and later the + SINGLETON field has been marked as private access. + If you get the exception shown above, then you are using an @@ -432,6 +433,10 @@ org.slf4j.impl.StaticLoggerBinder.SINGLETON from class org.slf4j.LoggerFactory binding will make the problem go away. + Please also read the FAQ entry on <a + href="#compatibility">backward compatibility</a> for a more + general explanation. + <hr /> </dd> ----------------------------------------------------------------------- Summary of changes: slf4j-site/src/site/pages/faq.html | 21 +++++++++++++-------- 1 files changed, 13 insertions(+), 8 deletions(-) hooks/post-receive -- SLF4J: Simple Logging Facade for Java

1 0

[Bug 235] New: Category class in log4j-over-slf4j does not contain getAllAppenders()
by bugzilla-daemon＠pixie.qos.ch 20 Aug '11

20 Aug '11

http://bugzilla.slf4j.org/show_bug.cgi?id=235 Summary: Category class in log4j-over-slf4j does not contain getAllAppenders() Product: SLF4J Version: 1.6.x Platform: All OS/Version: All Status: NEW Severity: major Priority: P1 Component: log4j-over-slf4j AssignedTo: slf4j-dev(a)qos.ch ReportedBy: anthony(a)whitford.com I am running into the same issue discussed here: http://slf4j.42922.n3.nabble.com/Sigar-and-log4j-over-slf4j-td2165576.html Sigar reports a stack trace like: java.lang.NoSuchMethodError: org.apache.log4j.Logger.getAllAppenders()Ljava/util/Enumeration; at org.hyperic.sigar.SigarLog.isLogConfigured(SigarLog.java:40) at org.hyperic.sigar.SigarLog.getLogger(SigarLog.java:49) at org.hyperic.sigar.SigarLog.getLogger(SigarLog.java:44) at org.hyperic.sigar.SigarLog.debug(SigarLog.java:60) at org.hyperic.sigar.Sigar.<clinit>(Sigar.java:108) And it was traced to the absence of getAllAppenders() in log4j-over-slf4j. Adding the missing method addresses the Sigar issue... public Enumeration getAllAppenders() { return new Enumeration() { public Object nextElement() { return null; } public boolean hasMoreElements() { return false; } }; } I'm unclear if the above method should be properly implemented, or if the mock stub is sufficient. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

Release of SLF4J version 1.6.2
by Ceki Gülcü 18 Aug '11

18 Aug '11

Hello all, I am happy to announce the immediate availability of SLF4J version 1.6.2 consisting bug fixes and documentation improvements. The Simple Logging Facade for Java or (SLF4J) serves as a simple facade or abstraction for various logging frameworks, e.g. java.util.logging, log4j and logback, allowing the end user to plug in the desired logging framework at deployment time. In the 1.6.x series, in the absence of an SLF4J binding, slf4j-api will default to a no-operation implementation discarding all log requests. Thus, instead of throwing an exception, SLF4J will emit a single warning message about the absence of a binding and proceed to discard all log requests without further protest. In other words, libraries no longer need to bundle an slf4j binding along with slf4j-api.jar in order to function out-of-the-box. Please refer to the the news page for precise details. http://www.slf4j.org/news.html You can download SLF4J, including full source code, class files and documentation on our download page, shown below. http://www.slf4j.org/download.html You can receive SLF4J related announcements by subscribing to the SLF4J announce mailing list. To subscribe to QOS.ch announce list, please visit the following URL. http://www.qos.ch/mailman/listinfo/announce -- Ceki Gülcü

1 0

[GIT] SLF4J: Simple Logging Facade for Java annotated tag, v_1.6.2, created. v_1.6.2
by git-noreply＠pixie.qos.ch 18 Aug '11

18 Aug '11

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "SLF4J: Simple Logging Facade for Java". The annotated tag, v_1.6.2 has been created at 9dc53c30053acb8f42af99ee90752621614cc73e (tag) tagging 1bb6ebb8f5b63569920101f79132f525437aa964 (commit) replaces v_1.6.1 tagged by Ceki Gulcu on Fri Aug 19 00:18:37 2011 +0200 - Log ----------------------------------------------------------------- tagging 1.6.2 Ceki Gulcu (44): doc edits added a link to Quartz Scheduler which now depende on SLF4J typo fix - started working on slf4j 1.6.2-SNAPSHOT - added sysout-over-slf4 as a "closely related" project in minor edits minor editing Merge branch 'master' of git.qos.ch:slf4j make log4j-over-slf4j run in jboss 4.2 Revert "make log4j-over-slf4j run in jboss 4.2" support for log4j in Jboss, untainted by s/logging/loxx/ refactoring typo support for X_TRACE level added a paragraph on excluding commons-logging added the isInstalled method to SLF4JBridgeHandler improved working clean up typo fix Merge branch 'master' of git.qos.ch:slf4j adding a link to qos.ch careers added a link to logback/jb.html from the header editorial changes added Velocity as an anti-pattern example added links to ActiveMQ, Camel and ServiceMix up the copyright notice to 2011 rewording ongoing edits Merge branch 'master' of git.qos.ch:/slf4j removing the job link version mismatch related editions precision regarding logback Merge branch 'master' of git.qos.ch:slf4j fix bug 225 fix url to announce ml archives added xwiki to the list og projects using slf4j Merge branch 'master' of git.qos.ch:slf4j alphabetical ordering illustrate slf4j binding and bridging - Fix #138 fixing #228 fixing #228 for MDC blurb on bug #228 - changing version to 1.6.2 updated diagram for legacy/bridging minor edits Heiko Seeberger (3): Initial contribution from SLF4S: Release 1.0.1 without stupid implicit conversion. OSGi stuff still missing! Added OSGi stuff to slf4j-scala-api, based on Felix Bundle plugin. Added Pax Runner composite provisioning file for easily firing up an OSGi container. ----------------------------------------------------------------------- hooks/post-receive -- SLF4J: Simple Logging Facade for Java

1 0

[GIT] SLF4J: Simple Logging Facade for Java branch, master, updated. v_1.6.1-47-g1bb6ebb
by git-noreply＠pixie.qos.ch 18 Aug '11

18 Aug '11

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "SLF4J: Simple Logging Facade for Java". The branch, master has been updated via 1bb6ebb8f5b63569920101f79132f525437aa964 (commit) from 3c8e6f6a7d705baa61f971782136fd1f2f1832c4 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://git.qos.ch/gitweb/?p=slf4j.git;a=commit;h=1bb6ebb8f5b63569920101f791… http://github.com/ceki/slf4j/commit/1bb6ebb8f5b63569920101f79132f525437aa964 commit 1bb6ebb8f5b63569920101f79132f525437aa964 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Fri Aug 19 00:10:08 2011 +0200 minor edits diff --git a/slf4j-site/src/site/pages/news.html b/slf4j-site/src/site/pages/news.html index b9578fb..acb6f1c 100644 --- a/slf4j-site/src/site/pages/news.html +++ b/slf4j-site/src/site/pages/news.html @@ -29,7 +29,7 @@ <hr noshade="noshade" size="1"/> - <h3>August xth, 2011 - Release of SLF4J 1.6.2</h3> + <h3>August 19th, 2011 - Release of SLF4J 1.6.2</h3> Fixed <a @@ -43,9 +43,9 @@ #228</a>. When running under IBM's JDK, and if no binding can be found, SLF4J will no longer throw a <code>NoClassDefFoundError</code>. Instead, it will default to an - NOP implementation instead. Under the same circumstances but with - Sun's JDK, SLF4J already defaulted to an NOP implementation since - release 1.6.0. + NOP implementation. Under the same circumstances but with Sun's + JDK, SLF4J already defaulted to an NOP implementation since release + 1.6.0. Added certain missing classes to the log4j-over-slf4j module as requested in <a ----------------------------------------------------------------------- Summary of changes: slf4j-site/src/site/pages/news.html | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) hooks/post-receive -- SLF4J: Simple Logging Facade for Java

1 0