December 2009 - slf4j-dev - mailman3.qos.ch

[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 31] Varargs for Logger methods
by bugzilla-daemon＠pixie.qos.ch 27 Dec '09

27 Dec '09

http://bugzilla.slf4j.org/show_bug.cgi?id=31 --- Comment #76 from Ceki Gulcu <listid(a)qos.ch> 2009-12-27 12:04:56 --- Thanks for providing this view in support of maintain JDK 1.4 compatibility. Given that the dates for End of Service Life for any given JDK are chosen arbitrarily by Sun Inc., without consulting the java user-base, the EOSL date is not a binding deadline but a mere indication of Sun's own position with respect to a given JDK. Logging is often used to diagnose problems in an application. Moreover, in many software projects, SLF4J has many nodes pointing at it as a dependency, unfolding in a rather complex dependency graph. Given these two arguments, SLF4J has the obligation to be as stable as possible and maintain backward compatibility. Having emphasized the importance of backward compatibility, I also think that backward compatibility can become a trap on the long run. So, not only is evolution of the SLF4J API welcome, it is necessary. We need to find a way to satisfy those two contradictory constraints, namely compatibility and evolution. This is where exploratory works, such as your fork, come into play. -- 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 27 Dec '09

27 Dec '09

http://bugzilla.slf4j.org/show_bug.cgi?id=31 --- Comment #75 from Joern Huxhorn <joern(a)huxhorn.de> 2009-12-27 03:07:31 --- Concerning the dropping of support for JDK<1.5 I'd like to cite the developer of the Twitter4J API about the reasons why he will stay compatible with 1.4 for an indefinite time. > Speaking of the EOSL of JDK1.4.2, there's tree reasons Twitter4J 2.1.0 will still support JDK1.4.2 which are: > 1. The EOSL is about Sun's JVM implementation. > IBM WebSphere6.0 is still alive and it doesn't support Java5 or later. > http://www-01.ibm.com/software/websphere/support/lifecycle/index_by_eos.html > http://groups.google.com/group/twitter4j/browse_thread/thread/12d98565c7884… > There are tons of active Oracle WebLogic Server 8.1 users which also don't support Java5. > WLS 8.1 has been EOL'ed three months ago, but customers can get extended support with $$$. > > I personally suggest them to migrate those proprietary and close-sourced application servers to open source application servers such as JBoss to save $$$. > > 2. Sun's JDK1.4.2 has been EOL'ed a year ago, but they're still supporting > They have "Java SE for Business Release" offering and customers who don't want to migrate to the latest JDK can get support from Sun with $$$. > http://java.sun.com/products/archive/eol.policy.html > And once Oracle acquired Sun, Oracle could launch a lifetime support offering. > -> P13 Extended Support > http://www.oracle.com/corporate/pricing/technology-price-list.pdf > > 3. There are so many "EOL? huh? who cares?" type of people. > As it is not that difficult to keep supporting JDK1.4.2 in OOTB way, I want Twitter4J to cover those people. I think there are several projects like that which would like to stay compatible with the smallest JDK version possible. And just for the record: The official (Sun) J2SE 5.0 End of Service Life was 2009-11-03. -- 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. v1.5.9.RC1-16-gcfb117d
by git-noreply＠pixie.qos.ch 27 Dec '09

27 Dec '09

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 cfb117d9e4c0fc44313328e8a8f9b74ad9bbf622 (commit) from 96aa1878e03f1c1600aeb67d62c2d090433f60b5 (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=cfb117d9e4c0fc44313328e8a8… http://github.com/ceki/slf4j/commit/cfb117d9e4c0fc44313328e8a8f9b74ad9bbf622 commit cfb117d9e4c0fc44313328e8a8f9b74ad9bbf622 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Sun Dec 27 00:54:37 2009 +0100 - added "In the presence of an exception/throwable, is it possible to parametizere a logging statement?" - mentioning provided scope as a convenient method for excluding commons-logging diff --git a/slf4j-site/src/site/pages/faq.html b/slf4j-site/src/site/pages/faq.html index 7e1223c..7da0d9d 100644 --- a/slf4j-site/src/site/pages/faq.html +++ b/slf4j-site/src/site/pages/faq.html @@ -130,6 +130,9 @@ without going through the static methods in <code>LoggerFactory</code>? </a></li> + <li><a href="#paramException">In the presence of an + exception/throwable, is it possible to parametizere a logging + statement?</a></li> </ol> @@ -543,16 +546,37 @@ org.slf4j.impl.StaticLoggerBinder.SINGLETON from class org.slf4j.LoggerFactory </dt> <dd> - A large number of Maven projects declare commons-logging - as a dependency. Thus, if you wish to migrate to SLF4J or use + A large number of Maven projects declare commons-logging as a + dependency. Thus, if you wish to migrate to SLF4J or use jcl-over-slf4j, you would need to declare a commons-logging - exclusion in all of your dependencies which transitively - depend on commons-logging. This can be an error prone - process. To alleviate the pain, Erik van Oosten has developed - a <a + exclusion in all of your dependencies which transitively depend + on commons-logging. This can be an error prone process. To + alleviate the pain, Erik van Oosten has developed a <a href="http://day-to-day-stuff.blogspot.com/2007/10/announcement-version-99-does-n…">clever hack around this problem.</a> + + Alternatively, commons-logging can be rather simply and + conveniently excluded as a dependency by declaring it in the + provided scope within the pom.xml file of your + project. The actual commons-logging classes would be provided by + jcl-over-slf4j. This translates into the following pom file + snippet: + + <pre class="prettyprint source"><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>${project.version}</version> +</dependency></pre> + + </dd> @@ -980,11 +1004,62 @@ logger.debug("The new entry is {}.", entry);</pre> <code>ILoggerFactory</code> interface as an alternative to inventing your own logging API. </dd> + + <dt><a name="paramException" href="#paramException">In the presence of an + exception/throwable, is it possible to parametizere a logging + statement?</a></dt> + + + <dd> + No. The SLF4J API does not support parametization in the + presence of an exception. Thus, + + <pre class="prettyprint">String s = "Hello world"; +try { + throw new NumberFormatException("..."); +} catch (NumberFormatException e) { + logger.error("Failed to format {}", s, e); +}</pre> + will NOT print the <code>NumberFormatException</code> nor its + stack trace. The java compiler will invoke the <a + href="http://www.slf4j.org/apidocs/org/slf4j/Logger.html#error%28java.lang.String…">error + method taking a String and two Object arguments</a>, which, + contrary to the programmer's most probable intention, will cause + the <code>NumberFormatException</code> to be ignored. This is one + of the unfortunate warts present in the SLF4J API. + + The only way to have the exception treated properly, is to + invoke the <a + href="http://www.slf4j.org/apidocs/org/slf4j/Logger.html#error%28java.lang.String…">error + method taking a String and a Throwable</a>. The correct code is + then, + + <pre class="prettyprint">String s = "Hello world"; +try { + throw new NumberFormatException("..."); +} catch (NumberFormatException e) { + // concatenation instead of parametrization! + logger.error("Failed to format "+ s, e); +}</pre> - </dl> + The second form MUST be employed in the presence of + exceptions. Given that exceptions are rare by definition, the cost + of concatenating "Failed format " and s should be + negligible in pracice. + + If you are user of the SLF4J API, and do not understand the + explanations in this question, you are advised to dwell on the + matter until it becomes clear. You have been warned. + + + </dd> + + + + </dl> ----------------------------------------------------------------------- Summary of changes: slf4j-site/src/site/pages/faq.html | 89 +++++++++++++++++++++++++++++++++--- 1 files changed, 82 insertions(+), 7 deletions(-) hooks/post-receive -- SLF4J: Simple Logging Facade for Java

2 1

[Bug 31] Varargs for Logger methods
by bugzilla-daemon＠pixie.qos.ch 16 Dec '09

16 Dec '09

http://bugzilla.slf4j.org/show_bug.cgi?id=31 --- Comment #74 from Joern Huxhorn <joern(a)huxhorn.de> 2009-12-16 11:51:35 --- In reply to comment #72: That is my suggestion, i.e. a) I suggested to add an additional, slimmer API that is a replacement of the current one, in a semi-source-compatible way (just changing imports). The old API would stay as it is to keep supporting projects that have not updated to the new version. In reply to comment #73: I was meaning a normal maven build where the 2.0.x dependency would override the 1.5.x dependency. In that case, the artifacts depending on 1.5.x would fail miserably upon execution. Even if some systems would be able to handle different versions of the same API in the same app this wouldn't help all the others. -- 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 165] New: Can't use slf4j with axis
by bugzilla-daemon＠pixie.qos.ch 16 Dec '09

16 Dec '09

http://bugzilla.slf4j.org/show_bug.cgi?id=165 Summary: Can't use slf4j with axis Product: SLF4J Version: 1.5.x Platform: PC OS/Version: Windows NT Status: NEW Severity: major Priority: P1 Component: Unspecified AssignedTo: slf4j-dev(a)qos.ch ReportedBy: mkr(a)archikart.de I tried to use slf4j together with axis. Therefore I use slf4j 1.5.8 (inclusive jcl-over-slf4j-1.5.8.jar), axis 1.4 and logback 0.9.16. But when I start my tomcat I get an exception. I read, there was a similar exception in the past which was fixed within the jcl104-over-slf4j.jar in 2006. But I couldn't find anything about my concrete problem. So I thought this problem could also be fixed here. org.apache.commons.discovery.DiscoveryException: Class org.apache.commons.logging.impl.SLF4JLogFactory does not implement org.apache.commons.logging.LogFactory at org.apache.commons.discovery.tools.ClassUtils.verifyAncestory(ClassUtils.java:180) [commons-discovery-0.2.jar:0.2] at org.apache.commons.discovery.tools.SPInterface.verifyAncestory(SPInterface.java:201) [commons-discovery-0.2.jar:0.2] at org.apache.commons.discovery.tools.SPInterface.newInstance(SPInterface.java:195) [commons-discovery-0.2.jar:0.2] at org.apache.commons.discovery.tools.DiscoverClass.newInstance(DiscoverClass.java:579) [commons-discovery-0.2.jar:0.2] at org.apache.commons.discovery.tools.DiscoverSingleton.find(DiscoverSingleton.java:418) [commons-discovery-0.2.jar:0.2] at org.apache.commons.discovery.tools.DiscoverSingleton.find(DiscoverSingleton.java:378) [commons-discovery-0.2.jar:0.2] at org.apache.axis.components.logger.LogFactory$1.run(LogFactory.java:45) [axis.jar:na] at java.security.AccessController.doPrivileged(Native Method) [na:1.6.0_11] at org.apache.axis.components.logger.LogFactory.getLogFactory(LogFactory.java:41) [axis.jar:na] at org.apache.axis.components.logger.LogFactory.<clinit>(LogFactory.java:33) [axis.jar:na] at org.apache.axis.transport.http.AxisServlet.<clinit>(AxisServlet.java:75) [axis.jar:na] at java.lang.Class.forName0(Native Method) [na:1.6.0_11] at java.lang.Class.forName(Class.java:169) [na:1.6.0_11] at org.apache.axis.transport.http.AxisServletBase.class$(AxisServletBase.java:59) [axis.jar:na] at org.apache.axis.transport.http.AxisServletBase.<clinit>(AxisServletBase.java:58) [axis.jar:na] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [na:1.6.0_11] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) [na:1.6.0_11] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) [na:1.6.0_11] at java.lang.reflect.Constructor.newInstance(Constructor.java:513) [na:1.6.0_11] at java.lang.Class.newInstance0(Class.java:355) [na:1.6.0_11] at java.lang.Class.newInstance(Class.java:308) [na:1.6.0_11] at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1115) [catalina.jar:na] at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:992) [catalina.jar:na] at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4058) [catalina.jar:na] at org.apache.catalina.core.StandardContext.start(StandardContext.java:4371) [catalina.jar:na] at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) [catalina.jar:na] at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) [catalina.jar:na] at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) [catalina.jar:na] at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) [catalina.jar:na] at org.apache.catalina.core.StandardService.start(StandardService.java:516) [catalina.jar:na] at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) [catalina.jar:na] at org.apache.catalina.startup.Catalina.start(Catalina.java:578) [catalina.jar:na] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [na:1.6.0_11] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [na:1.6.0_11] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [na:1.6.0_11] at java.lang.reflect.Method.invoke(Method.java:597) [na:1.6.0_11] at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) [bootstrap.jar:na] at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) [bootstrap.jar:na] -- 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 31] Varargs for Logger methods
by bugzilla-daemon＠pixie.qos.ch 16 Dec '09

16 Dec '09

http://bugzilla.slf4j.org/show_bug.cgi?id=31 --- Comment #73 from Gunnar Wagenknecht <gunnar(a)wagenknecht.org> 2009-12-16 10:32:21 --- (In reply to comment #71) > This would mean that *every* module would have to be upgraded before anything > would work again - and this is absolutely impossible. Not necessarily. It depends on the runtime. Some allow running different versions of the same library in parallel. -- 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 16 Dec '09

16 Dec '09

http://bugzilla.slf4j.org/show_bug.cgi?id=31 --- Comment #72 from Ralph Goers <rgoers(a)apache.org> 2009-12-16 02:27:16 --- To support B) you could keep the existing API but add a new API in a different package or use org.slf4j2. -- 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