- slf4j-dev - mailman3.qos.ch

[Bug 169] New: Better introspection into logging setup
by bugzilla-daemon＠pixie.qos.ch 06 Mar '10

06 Mar '10

http://bugzilla.slf4j.org/show_bug.cgi?id=169 Summary: Better introspection into logging setup Product: SLF4J Version: 1.5.x Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: Implementations AssignedTo: slf4j-dev(a)qos.ch ReportedBy: jo(a)durchholz.org I'd like to - have a way to enumerate all SLF4J loggers configured, and - get an event whenever any SLF4J logger has its configuration changed. USE CASE: I could improve SLF4JBridgeHandler with that. I have a situation where I need to set j.u.l. logging to ALL for some loggers to get the information I want, and WARN for other loggers to keep performance to acceptable levels. Currently, I'm forced to configure both slf4j *and* j.u.l. This is error-prone because I have to keep redundant logging configurations, and because the logging levels do not map 1:1. With the enumeration, I could initialize a j.u.l. logger for every configured slf4j logger, at a compatible logging level. With the events, I could keep the j.u.l. configuration in sync with the slf4j configuration. HELPING WITH THE WORK I can contribute the code, but I can't decide where in SLF4J's architecture it should go. -- 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

BasicMDCAdapter
by Gunnar Wagenknecht 06 Mar '10

06 Mar '10

Hi, I noticed that the BasicMDCAdapter uses a regular InheritableThreadLocal while the LogbackMDCAdapter uses a custom "CopyOnInheritThreadLocal". The JavaDoc implies that they should be similar. Any reasons why the difference in implementation was chosen (perhaps performance, memory)? Also BasicMDCAdapter seems to require Java 5 although it's part of the SLF4J API library. It calls ThreadLocal#remove() directly (without reflection) which does not exists in JDK <= 1.4. -Gunnar -- Gunnar Wagenknecht gunnar(a)wagenknecht.org http://wagenknecht.org/

2 1

jul-to-slf4j bridge via LogManager, prototype
by work_registries＠web.de 06 Mar '10

06 Mar '10

First, my apoligies for using an alias email, its Juergen, not Max :) Second, having subscribed in digest mode, I found your reply in the archive and wanted to answer, but breaking the discussion chain. The implementation tries to improvement shortcomings of jul-to-slf4j bridge mentioned in http://www.slf4j.org/legacy.html#jul-to-slf4j: * java.util.logging.Logger being a core java package class, slf4j bridging by providing replacements for other logging classes like log4j.Logger does not work. * SLF4JBridgeHandler being a handler implies that it's still necessary to configure jul Loggers in parallel to the slf4j backend or at least to forward every log event to slf4j handler * jul-to-slf4j translation therefore has - as mentioned - negative performance impact The idea is to have the jul Logger class replaced (similar to other bridges) but not by providing a new java.util.logging.Logger, but by providing a new slf4j LogManager that creates java.util.logging.Logger based loggers. You gain the same advantages as e.g. by providing a log4j.Logger replacement. Based on sun jvm configuration options for LogManager as mentioned in http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/LogManager.html: -Djava.util.logging.manager=org.slf4j.bridge.LogManager adding jul-to-slf4j bridge classes (LogManager, Logger) to bootclasspath via -Xbootclasspath/a:jul-to-slf4j-boot.jar (or putting it into /ext dir?) Issues: * Properly translating all public/protected jul Logger methods to corresponding slf4j Logger methods is not completely/properly done in the prototype implementation I provided. * Allowing a slf4j LogManager configuration (similar to jul LogManager being configured via logging.properties) e.g. for providing a mapping for jul Level to slf4j Levels, is also coded and not configurable. For special consideration is the fact that other java core classes make use of jul Logger immediately after jvm startup (at least in my case running jboss-4.3.2.GA). So either slf4j + backend is provided as a bootclasspath as well or - as I tried to do in my prototype - slf4j jul Logger replacement tries to create slf4j Loggers - I'm using Thread ContextClassLoader for this - and if successful - permamently (possible memory leak?) wires slf4j jul Logger to slf4j Logger. Or if unsuccessful (as long as slf4j Loggers + backend are not in Classpath) simply calls its superclass jul Logger methods. In that case it might still be necessary for slf4j LogManager to call jul LogManager configuration/methods to allow for jul logging configuration being in effect at early system startup until slf4j replacement kicks in. * slf4j jul Logger must be usable without other slf4j class references -> sadly reflection necessary, but still better performance than with BridgeHandler? * repeatedly tries to create slf4j logger on every method invocation until wired -> expensive repetitive checks for slf4j Logger in classpath, but only until slf4j available Hope I could explain my thoughts on that matter and that it - if considered - proves to be more of an improvement than a complication. gr, Juergen In reply to: Hello Max, Thank you for this contribution. Perhaps a stupid question but what is the purpose of replacing jul's LogManager and creating a Logger class extending java.util.logging.Logger? You say that you were unsatisfied with the existing jul-to-slf4j adapter, how so and how does your implementation improve things? On 04/03/2010 6:36 AM, Max Mustermann wrote: > Hi! > > Being unsatisfied with existing jul-to-slf4j adapter I tried to search > for a better way to bridge jul to slf4j > > Attached you find a prototype implementation based on the following > concepts: > > * A jul LogManager extending java.util.logging.LogManager creating newly > introduced org.slf4j.bridge.Logger subclassed from java.util.logging.Logger > * setting LogManager via jvm property: > -Djava.util.logging.manager=org.slf4j.bridge.LogManager > * adding LogManager / Logger to bootclasspath: > -Xbootclasspath/a:path/to/jul-to-slf4j.jar > * LogManager has mapping for jul logging call source Level to target jul > Level, mapping for target jul Level to slf4j log methods: e.g. source > Level.FINEST -> target Level.FINE, target Level.FINE -> slf4j trace > * LogManager mapping hardcoded but possibly configurable by > adapting/improving readConfiguration() / readConfiguration(InputStream) > * A org.slf4j.bridge.Logger extending java.util.logging.Logger that has > a very simple lazy slf4j logger lookup + forwarding of most methods to > slf4j methods. NEEDS IMPROVEMENT: logrb methods, entering, exiting, > throwing, etc. > * As org.slf4j.bridge.Logger is probably instantiated very early in > system startup (replacing sun internally used Logger instances as well) > it cannot be assumed that slf4j is already in classpath. So I have done > a lazy lookup of Slf4j Logger via reflection. If found, it keeps a > reference (possible memory leak?), if not, it falls back to > java.util.logging.Logger super calls. The slf4j method invokations are > therefore via reflection as well. Possible performance improvments by > caching Method elements, maybe use java.lang.reflect.Proxy, bytecode > rewriting, ... ? > > > Tried it with jboss-4.2.3.GA and it seemed to work. > > greetings, J?rgen ___________________________________________________________ WEB.DE DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.! http://produkte.web.de/go/02/

2 1

jul-to-slf4j bridge via LogManager, prototype
by Max Mustermann 04 Mar '10

04 Mar '10

2 1

[GIT] SLF4J: Simple Logging Facade for Java branch, master, updated. v1.5.9.RC1-25-g59753aa
by git-noreply＠pixie.qos.ch 27 Feb '10

27 Feb '10

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 59753aaec81369c7f2b59818587cbedaf005a0c1 (commit) from 4901ff5a22177bf6165beabde79d3fe135e9dd43 (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=59753aaec81369c7f2b5981858… http://github.com/ceki/slf4j/commit/59753aaec81369c7f2b59818587cbedaf005a0c1 commit 59753aaec81369c7f2b59818587cbedaf005a0c1 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Sat Feb 27 15:24:54 2010 +0100 added a FAQ entry about wrapping SLF4J diff --git a/slf4j-site/src/site/pages/faq.html b/slf4j-site/src/site/pages/faq.html index 7da0d9d..eb9661c 100644 --- a/slf4j-site/src/site/pages/faq.html +++ b/slf4j-site/src/site/pages/faq.html @@ -71,6 +71,13 @@ </li> <li> + <a href="#optional_dependency">In order to reduce the number of + dependencies of our software we would like to make SLF4J an + optional dependency. Is that a good idea? + </a> + </li> + + <li> <a href="#maven2">What about Maven 2 transitive dependencies? </a> @@ -485,19 +492,87 @@ org.slf4j.impl.StaticLoggerBinder.SINGLETON from class org.slf4j.LoggerFactory </dt> <dd> - Embedded components such as libraries do not need and - should not configure the underlying logging system. They - invoke SLF4J to log but should let the end-user configure the - logging environment. When embedded components try to configure - logging on their own, they often override the end-user's - wishes. At the end of the day, it is the end-user who has to - read the logs and process them. She should be the person to - decide how she wants her logging configured. + Embedded components such as libraries not only do not need + to configure the underlying logging framework, they really + should not do so. They should invoke SLF4J to log but should + let the end-user configure the logging environment. When + embedded components try to configure logging on their own, they + often override the end-user's wishes. At the end of the day, it + is the end-user who has to read the logs and process them. She + should be the person to decide how she wants her logging + configured. <hr/> </dd> +  + + <dt> + <a name="optional_dependency" href="#optional_dependency">In + order to reduce the number of dependencies of our software we + would like to make SLF4J an optional dependency. Is that a good + idea? + </a> + </dt> + + <dd> + <a + href="http://stackoverflow.com/questions/978670/is-it-worth-wrapping-a-logging-fr…">This + question pops up</a> whenever a software project reaches a point + where it needs to devise a logging strategy. + + + Let Wombat be a software library with very few + dependencies. If SLF4J is chosen as Wombat's logging API, then a + new dependency on slf4j-api.jar will be added to + Wombat's list of dependencies. Given that writing a logging + wrapper does not seem that hard, some developers will be tempted + to wrap SLF4J and link with it only if it is already present on + the classpath, making SLF4J an optional dependency of Wombat. In + addition to solving the dependency problem, the wrapper will + isolate Wombat from SLF4J;s API ensuring that logging in Wombat + is future-proof. + + + On the other hand, any SLF4J-wrapper by definition depends on + SLF4J. It is bound to have the same general API. If in the + future a new and significantly different logging API comes + along, code that uses the wrapper will be equally difficult to + migrate to the new API as code that used SLF4J directly. Thus, + the wrapper is not likely to future-proof your code, but to make + it heavier by adding an additional indirection on top SLF4J + which is an indirection in itself. + + + While one can come up with a seemingly working SLF4J-wrapper + within hours, many small technical issues will emerge over time + which Wombat developers will have to deal with. Note that SLF4J + has evolved over several years and has 170 bug reports filed + against it. + + It is reasonable to assume that in most projects Wombat will + be one dependency among many. If each library had its own + logging wrapper, then each wrapper would presumably need to be + configured separately. Thus, instead of having to deal with one + logging framework, namely SLF4J, the user of Wombat would have + to detail with Wombat's logging wrapper as well. The problem + will be compounded by each framework that comes up with its own + wrapper in order to make SLF4J optional. (Configuring 5 + different logging wrappers is not exactly exciting nor + endearing.) + + + For this reason, developers of frameworks should resist the + temptation to write their own logging wrapper. Not only is it a + waste of time of the developer, it will actually make life more + difficult for the users of said frameworks. + + </dd> + + +  + <dt><a name="maven2" href="#maven2">What about Maven2 transitive dependencies? </a> </dt> @@ -531,7 +606,7 @@ org.slf4j.impl.StaticLoggerBinder.SINGLETON from class org.slf4j.LoggerFactory Thus, as far as your users are concerned you are exporting slf4j-api as a transitive dependency of your library, but not - any SLF4J-binding or an underlying logging system. + any SLF4J-binding or any underlying logging system. <hr/> ----------------------------------------------------------------------- Summary of changes: slf4j-site/src/site/pages/faq.html | 93 ++++++++++++++++++++++++++++++++---- 1 files changed, 84 insertions(+), 9 deletions(-) hooks/post-receive -- SLF4J: Simple Logging Facade for Java

1 0

Fwd: global exclusions in Maven
by Ceki Gülcü 27 Feb '10

27 Feb '10

FYI. I just sent this to Matt Raible (the author of appfuse) who has asked for global exclusions in Maven. -------- Original Message -------- Subject: global exclusions in Maven Date: Sat, 27 Feb 2010 15:09:12 +0100 From: Ceki Gülcü <ceki(a)qos.ch> To: matt@... CC: Ceki Gulcu <ceki(a)qos.ch> Hello Matt, I just wanted to inform you that even without global exclusions in Maven, it is still possible to exclude commons logging quite conveniently. Given that jcl-over-slf4j is a perfect binary replacement for commons logging, simply declare commons-logging in the provided scope in the a project top-level pom.xml file. This translates into the following pom file snippet: <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> <version>1.1.1</version> <scope>provided</scope> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>jcl-over-slf4j</artifactId> <version>1.5.11</version> </dependency> There is an SLF4J FAQ entry discussing this same point [1]. I don't believe global exclusions would buy us anything more than what is already available by declaring CL in the provided scope. Cheers, -- Ceki [1] http://slf4j.org/faq.html#excludingJCL

1 0

[GIT] SLF4J: Simple Logging Facade for Java branch, master, updated. v1.5.9.RC1-24-g4901ff5
by git-noreply＠pixie.qos.ch 25 Feb '10

25 Feb '10

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 4901ff5a22177bf6165beabde79d3fe135e9dd43 (commit) from dae55b822906cbb5b701e6f58199e9b50c0e2df8 (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=4901ff5a22177bf6165beabde7… http://github.com/ceki/slf4j/commit/4901ff5a22177bf6165beabde79d3fe135e9dd43 commit 4901ff5a22177bf6165beabde79d3fe135e9dd43 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Thu Feb 25 15:58:07 2010 +0100 - minor edits in the docs diff --git a/slf4j-site/src/site/pages/docs.html b/slf4j-site/src/site/pages/docs.html index 5d5dc62..d1fc77c 100644 --- a/slf4j-site/src/site/pages/docs.html +++ b/slf4j-site/src/site/pages/docs.html @@ -65,7 +65,8 @@ </li> <li> - <a href="slf4j-in-10-slides.ppt">SLF4J in 10 slides</a>, by Ceki Gülcü + <a href="slf4j-in-10-slides.ppt">JUnit 4 Test Logging Tips using + SLF4J</a>, by Ceki Gülc&uuml </li> <li> @@ -84,6 +85,10 @@ Version 99 Does Not Exist</a>, by Erik van Oosten </li> + <li> + <a href="http://www.catosplace.net/blogs/personal/?p=442">JUnit + 4 Test Logging Tips using SLF4J</a>, by Pete Sellars + </li> <li> <a diff --git a/slf4j-site/src/site/pages/legacy.html b/slf4j-site/src/site/pages/legacy.html index fa8d54d..7623b9d 100644 --- a/slf4j-site/src/site/pages/legacy.html +++ b/slf4j-site/src/site/pages/legacy.html @@ -60,8 +60,12 @@ commons-logging.jar with jcl-over-slf4j.jar. Subsequently, the selection of the underlying logging framework will be done by SLF4J instead of JCL - but without the class loader headaches. The underlying logging - framework can be any of the frameworks supported by SLF4J. + <a href="http://articles.qos.ch/classloader.html">but without the + class loader headaches plaguing JCL</a>. The underlying logging + framework can be any of the frameworks supported by SLF4J. Often + times, replacing commons-logging.jar with + jcl-over-slf4j.jar will immediately and permanently solve + class loader issues related to commons logging. <h3>slf4j-jcl.jar</h3> diff --git a/slf4j-site/src/site/pages/manual.html b/slf4j-site/src/site/pages/manual.html index 6d1b1dc..aebe651 100644 --- a/slf4j-site/src/site/pages/manual.html +++ b/slf4j-site/src/site/pages/manual.html @@ -131,8 +131,7 @@ public class HelloWorld { <dt>slf4j-jdk14-${project.version}.jar </dt> <dd>Binding for java.util.logging, also referred to as JDK 1.4 - logging (<a - href="http://www.exampledepot.com/egs/java.util.logging/pkg.html">examples</a>)</dd> + logging </dd> <dt>slf4j-jcl-${project.version}.jar</dt> ----------------------------------------------------------------------- Summary of changes: slf4j-site/src/site/pages/docs.html | 7 ++++++- slf4j-site/src/site/pages/legacy.html | 8 ++++++-- slf4j-site/src/site/pages/manual.html | 3 +-- 3 files changed, 13 insertions(+), 5 deletions(-) hooks/post-receive -- SLF4J: Simple Logging Facade for Java

1 0

[Bug 167] New: Document StackOverflow Exception when an infinite delegation cycle occurs
by bugzilla-daemon＠pixie.qos.ch 25 Feb '10

25 Feb '10

http://bugzilla.slf4j.org/show_bug.cgi?id=167 Summary: Document StackOverflow Exception when an infinite delegation cycle occurs Product: SLF4J Version: 1.5.x Platform: PC OS/Version: Windows NT Status: NEW Severity: enhancement Priority: P1 Component: Unspecified AssignedTo: slf4j-dev(a)qos.ch ReportedBy: listid(a)qos.ch Some people blindly put SLF4J artifacts causing stack overflows. This should be documented in the errors page with links from the legacy page. -- 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 168] New: Category.log(String FQCN, Priority p, Object msg, Throwable t) method throws UnsupportedOperationException
by bugzilla-daemon＠pixie.qos.ch 25 Feb '10

25 Feb '10

http://bugzilla.slf4j.org/show_bug.cgi?id=168 Summary: Category.log(String FQCN, Priority p, Object msg, Throwable t) method throws UnsupportedOperationException Product: SLF4J Version: 1.5.x Platform: PC OS/Version: Windows NT Status: NEW Severity: major Priority: P1 Component: log4j-over-slf4j AssignedTo: slf4j-dev(a)qos.ch ReportedBy: listid(a)qos.ch Seth Call reports: http://www.qos.ch/pipermail/slf4j-user/2010-February/000889.html It appears that but not certain that a logback appender is invoking a library using log4j during its initialization which retrieves a NOPLogger. See http://www.qos.ch/pipermail/slf4j-user/2010-February/000892.html Solution is to change the Category.log(String FQCN, Priority p, Object msg, Throwable t) method from public void log(String FQCN, Priority p, Object msg, Throwable t) { int levelInt = priorityToLevelInt(p); differentiatedLog(null, FQCN, levelInt, msg, t); } public void log(String FQCN, Priority p, Object msg, Throwable t) { int levelInt = priorityToLevelInt(p); if (locationAwareLogger != null) { locationAwareLogger.log(null, FQCN, levelInt, convertToString(msg), t); } else { throw new UnsupportedOperationException("The logger [" + slf4jLogger + "] does not seem to be location aware."); } } -- 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

Release of SLF4J version 1.5.11
by Ceki Gülcü 25 Feb '10

25 Feb '10

Hello all, I am happy to announce the immediate availability of SLF4J version 1.5.11 consisting of bug fixes and minor enhancements. It is totally compatible with SLF4J version 1.5.10. 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ü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch

1 0