- slf4j-dev - mailman3.qos.ch

licensing
by Espák Miklós 13 Jan '10

13 Jan '10

Hi, I am developing a framework over Prolog APIs for Java. It is a facade for Prolog implementations, just like SLF4J is for logging APIs. I used some code from SLF4J, and I have modified that for my purposes. I renamed the files (e.g. LoggerFactory to ProverFactory). I want to release the software under LGPL. The MIT license of SLF4J permits this. Which of the following is the correct way of doing this? 1. I drop the MIT licence, and use LGPL, reserving the copyright statement of the original authors, and adding my copyright, e.g. in the following way: "Copyright by <me>, under LGPL License. Credits to XY for the original code of ZYX from library SLF4J. 2. I keep the MIT licence and the copyright statement of the original authors and add my copyright because of the modifications. This way certain files would be licenced under the MIT licence, and most of the source files under LGPL. I would prefer the first version, if possible, so that I do not need to use several licences in the same project. Regards, Miklos Espak

2 2

[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

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

15 Dec '09

http://bugzilla.slf4j.org/show_bug.cgi?id=31 --- Comment #71 from Joern Huxhorn <joern(a)huxhorn.de> 2009-12-15 22:06:23 --- In reply to comment #70: Thanks for the thumbs-up! I'd obviously vote for a) but I can explain why b) wouldn't fly, too. If SLF4J would be bumped to 2.0 without staying binary-compatible with 1.5.x and you'd have artifacts where one would depend on 1.5.x and the other on 2.0.x then everything would explode. This would mean that *every* module would have to be upgraded before anything would work again - and this is absolutely impossible. -- 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 15 Dec '09

15 Dec '09

http://bugzilla.slf4j.org/show_bug.cgi?id=31 --- Comment #70 from Rick Beton <rick.beton(a)gmail.com> 2009-12-15 19:31:17 --- As a user, what I want is a *simple* API based on Java 1.5. I'd also like my existing code not to break. The crux of this lengthy three-year discussion is that these are conflicting requirements in detail. Therefore I generally support either a. Joern Huxhorn's suggestion for a new slimmer API: throw away unwanted methods, even throw away methods with explicit Throwables on the basis of the principle of least surprise (I've seen FAR too many mistakes made with incorrect logging of Throwables). The only downside of Joern's idea is that the Eclipse organize-imports operation faces a new ambiguity because of the new packages containing Logger and LoggerFactory as well as the old packages. And there's more to document and maintain. b. Bump up to v2.0 and provide source-level backward compatibility only. By adding methods with varargs whilst keeping old methods, there might be compilation failures caused by method ambiguities. So don't do that. Instead, slim down the API to avoid ambiguities, even though this will provide only source-level backward-compatibility, rather than binary-level. That gets my vote. SLF4J gets better! Either way, drop the methods with Throwable arguments when varargs will do instead. Rick -- 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