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
_______________________________________________
slf4j-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev
