On 08/03/2010 2:49 PM, Joern Huxhorn wrote:
On 06.03.2010, at 18:13, Ceki Gülcü wrote:
As mentioned in comment #10 dated 2007-10-10 on bug 31, we can have binary compatibility as long as
logger.trace|debug|info|warn|error(String, Object[]) logger.trace|debug|info|warn|error(Marker, String, Object[])
are changed to
logger.trace|debug|info|warn|error(String, Object...) logger.trace|debug|info|warn|error(Marker, String, Object...)
with all the other methods remaining unchanged.
That's not entirely true. As you stated in that comment, compatibility is not the case if someone compiles against SLF4J v2 (with varargs) but the container uses JDK 1.4. http://bugzilla.slf4j.org/show_bug.cgi?id=31#c75 I fear that SLF4J v2 might sneak up on some people by either not RTFM of SLF4J v2 or by some dependency where the developers did not RTFM the SLF4J v2 manual. It wouldn't be our fault in both cases but it would boil down to "Updating xyz broke my build" subjects in mailinglists with the explanation that it was because of the SLF4J dependency.
But that's OK isn't it? If project A is built under JDK 1.4, upgrading to SLF4J v2 would result in an incompatible class version during the build and the developer will be forced to stay with slf4j 1.5.x, which is OK. Moreover, while a container may be built using JDK 1.4 I don't see how a container could force the use of JDK 1.4. The end-user can always chose to use a later version of the JDK. My comment was about a container exporting its version of SLF4J to the application, but as long as SLF4J v1 and v2 are binary compatible that would not be a problem. If v1 and v2 are NOT binary compatible, then that's a different matter altogether.
I find this BasicMDCAdapter.remove episode really puzzling. The only simple explanation I see is that few SLF4J users run under JDK 1.4 or more accurately the overlap of org.slf4j.MDC and JDK 1.4 use corresponds to a very small number of users.
You're right. But there's also the possibility that people are only putting values into MDC without ever removing them again, overwriting them instead.
Yes, that's also a possibility.
Before I switched all my stuff to SLF4J I was using commons-logging. This was the case for all the projects I was involved in. CL did not support MDC and I think that this is one of the reasons why MDC is - even now - quite underused. Lots of people switched their codebase over to SLF4J by a simple search & destroy, I guess.
Search and replace, not destroy. :-)
It's a shame that there's no tool to analyze the whole central Maven2 repository concerning this, or is there? It would be great if there was a way to find out which modules depend on SLF4J (either directly or transitively) and are still 1.4.
Let's google it. :-)
Did you succeed?
No, that's was my feeble attepmt at cracking a joke.
If we are going to re-implement org.slf4j.Logger under org.slf4j.n.Logger, we might as well call it org.newslf4j.Logger and start over from scratch. Copying the API to new packages avoids conflicts but otherwise constitutes a radical break.
Yes, it does. But it also cleans up the API and adds some very substantial features.
There are lots of methods that aren't necessary anymore with varargs and exception support built in.
Additional ones would be extremely nice to have. Methods supporting the (or a) Message interface would enable the user to define his own application-specific message implementation which would bring a whole new level to the framework. He could access those special messages without parsing in specifically written appenders.
I've also added log(Level,....) and isEnabled(Level[,Marker])-methods for cases where the actual level a call uses is determined programmatically. This is something that we needed on several occasions, too.
But additional methods can't be added to the original SLF4J because, as you correctly enforce, SLF4J API is frozen and must stay that way.
What I suggest is a bit like the junit package switch. With JUnit 4 the package changed from junit to org.junit. The original junit keeps working as before but new stuff was added in org.junit.
Good point. There are several differences between the Junit case and SLF4J. Junit3 had maybe 99% market share of the unit testing API "market". The market shared being eroded by TestNG which brought in annotations as significant improvement over Junit3. I don't think Junit4 would exist without TestNG competitive pressure. As far as I know, SLF4J has no competition from a "feature" point of view. Of course, there is JCL, jul and log4j but they all have less advanced user-facing logging APIs.
You are right: the package could be named anything.
The only reasons I choose org.slf4j.n was a) making a switch easy by just adding .n to import statements b) using the SLF4J brand because it's established and people already believe/put trust in it c) it was merely a suggestion
The main point, though, is, that there would be zero impact on any existing code base. Everything, even SLF4J implementations, don't have to do anything. The new API would be supported anyway.
In case of JDK>=1.5 implementations like Logback, it does make a lot of sense to implement the new API directly (so the Message reaches the appenders - instead of an String) and wrapping the other way around, i.e. using a wrapper to support the original SLF4J API (which is already provided in the new Logger interface via getOldLogger() method). But this isn't required for org.slf4j.n to work.
IMO, support for messages can be sufficiently important as to justify a new API but I am not convinced yet. By the way, the invitation made to Juergen regarding a link at a prominent place on the SLF4J web-site extends to your fork as well. I'll gladly add a link to http://github.com/huxi/slf4j/tree/slf4j-redesign with a description provided by you so that can people can try it out and provide feedback. WDYT? -- Ceki