February 2010 - slf4j-dev - mailman3.qos.ch

[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 163] New: Copy & paste of LoggerFactory.getLogger
by bugzilla-daemon＠pixie.qos.ch 19 Jul '11

19 Jul '11

http://bugzilla.slf4j.org/show_bug.cgi?id=163 Summary: Copy & paste of LoggerFactory.getLogger Product: SLF4J Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: thomas.tom.mueller(a)gmail.com This is a feature request. Currently, when I create a new logger in a class, I copy & paste the following line from another class: private static Logger log = LoggerFactory.getLogger(AcmeImpl.class); Sometimes I forget to change the class name. SLF4J could help me here. I suggest to add a new method, so the class name is not required, so that I can copy & paste the line without having to remember that I have to change the class name. Also, it's a bit shorter: private static Logger log = LoggerFactory.getCallerClassLogger(); This is copy & paste friendly. The implementation is tricky, but trivial once you understand it: getCallerClassLogger() { return getLogger(new Error().getStackTrace()[1].getClassName()); } There is a project that tries to solve the copy & paste problem: http://code.google.com/p/morbok/ -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 40

[Bug 164] New: NPE on LoggerFactory.singleImplementationSanityCheck
by bugzilla-daemon＠pixie.qos.ch 04 Apr '10

04 Apr '10

http://bugzilla.slf4j.org/show_bug.cgi?id=164 Summary: NPE on LoggerFactory.singleImplementationSanityCheck Product: SLF4J Version: 1.5.x Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: joakim.erdfelt(a)gmail.com This occurs on slf4j-api 1.5.7 and 1.5.8 when using logback 0.9.18 It does not occur on slf4j-api 1.5.6 Note: the environment being used has various java.endorsed.dirs setup where the logging is initialized. This being not very normal, it could be the reason for this NPE, as I believe LoggerFactory.class.getClassLoader() will return null in this scenario. java.lang.NullPointerException at org.slf4j.LoggerFactory.singleImplementationSanityCheck(LoggerFactory.java:192) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:113) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:269) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:242) at org.eclipse.jetty.util.log.Slf4jLog.<init>(Slf4jLog.java:33) at org.eclipse.jetty.util.log.Slf4jLog.<init>(Slf4jLog.java:28) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 3

[Bug 161] New: log4j-over-slf4j doesn't implement org.apache.log4j.spi. RootCategory
by bugzilla-daemon＠pixie.qos.ch 04 Apr '10

04 Apr '10

http://bugzilla.slf4j.org/show_bug.cgi?id=161 Summary: log4j-over-slf4j doesn't implement org.apache.log4j.spi.RootCategory Product: SLF4J Version: 1.5.x Platform: PC OS/Version: Windows XP Status: NEW Severity: major Priority: P1 Component: log4j-over-slf4j AssignedTo: dev(a)slf4j.org ReportedBy: boris(a)granveaud.com Some libraries (for example SmartGWT EE) use the classes located in package org.apache.log4j.spi. These classes should be emulated in log4j-over-slf4j. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 4

[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

[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