Hi Ceki,
I suppose I hadn't expected any of that would be an issue with a
change that (from SLF4J API's perspective) would be solely adding new
method signatures to the Logger interface whilst altering none of the
existing ones; I think it should be fully backwards compatible with
clients compiled against previous versions of SLF4J from a binary
perspective. I see you did precisely that, adding the trace level in
version 1.4. A quick test suggests that an app using a library
compiled against 1.5.6 and another library compiled against 1.5.7-
SNAPSHOT with the extra methods added to Logger by me responds quite
happily so long as I have my 1.5.7-SNAPSHOT jar and a compatible
implementation on the classpath.
Anyway, not exactly a big problem! I was primarily asking out of
curiousity as to whether it was a deliberate design decision or just a
matter of not done originally and now not worth the pain of doing.
Rob
On 27 May 2009, at 14:19, Ceki Gulcu wrote:
Hello Robert,
As Jukka's mail indicates, the modification you suggest is not
necessarily for the better. I personally tend to agree with
Jukka. There are probably others who would be more inclined to agree
with your position. However, even in cases where we all agree on the
merits of a change, e.g. varargs [1], given that SLF4J is used by a
large number of components, we can't take the risk of making backward
incompatible changes. Even small *internal* changes have had important
repercussions in the past [2]. Changing major version numbers, would
not be of any help. If your project, say A, depends on library B which
uses SLF4J, and on library C which used SLF4J-2, assuming SLF4J and
SLF4J-2 are incompatible, you'd be stuck and probably reduced to
cursing SLF4J.
[1] http://bugzilla.slf4j.org/show_bug.cgi?id=31
[2] http://slf4j.org/faq.html#IllegalAccessError
[3] http://slf4j.org/faq.html#version_checks
Robert Elliot wrote:
Just curious about this - I often find myself catching an exception
and not really having anything to say about it other than that I
want to log the exception. So I end up calling
log.error(ex.getMessage(), ex) - which seems a bit redundant as
I'll get the message out anyway.
I understand why you couldn't do it in log4j, because there was
already an error(Object) and so you'd have confusion over whether
they wanted to log the exception including stack trace or just the
exception's toString. But as that vagueness has been cleared up in
SLF4J it would be quite clear which method you were calling -
error(Throwable) or error(String).
Is it just too late to add it, since all SLF4J implementations
would need to be altered to implement it? Ceki does effectively
control rather a lot of the SLF4J implementations (the JULI one,
the Log4J one, logback and slf4j-simple). If it were added (say in
a theoretical SLF4J 2) then I presume that it would still be OK for
the end user - a library compiled against SLF4J 1.x would still
work alongside libraries compiled against SLF4J 2 and using an
SLF4J 2 implementation.
Just a query.
Rob
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework
for Java.
http://logback.qos.ch
_______________________________________________
dev mailing list
dev@slf4j.org
http://www.slf4j.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@slf4j.org
http://www.slf4j.org/mailman/listinfo/dev