[slf4j-dev] [Bug 31] Varargs for Logger methods

bugzilla-daemon at pixie.qos.ch bugzilla-daemon at pixie.qos.ch
Thu Apr 24 19:30:23 CEST 2008


http://bugzilla.slf4j.org/show_bug.cgi?id=31





------- Comment #24 from listid at qos.ch  2008-04-24 19:30 -------
> On the other hand, isn't this comparable to a situation where a
> container uses an old version of some API, reintroducing long-fixed
> bugs?

It is comparable although a bug is not the same thing as a JDK version
dependency. There may be valid reasons for requiring JDK 1.4 whereas
developers rarely demand a bug as a requirement.

> Since Geronimo requires JDK 1.5 it would be a mistake (more or less)
> to include slf4j-api instead of slf4j-api-jdk15, right?

Even if a future versions of Geronimo decides to upgrade to
slf4j-api-jdk15, what happens to those who use an older version of
Geronimo? Applications (requiring slf4j-api-jdk15) will not work with
an older version of Geronimo.

What happens if application server X, in addition to Geronimo, decides
to adopt SLF4J, say slf4j-api and not slf4j-api-jdk15. Then, an
application will work under the new Geronimo but not X.

Experience with JCL has shown that it is impossible to anticipate all
the environments in which the logging abstraction API will run. It is
a major headache to support our users when they run into problems in a
particular set up. 

Even in the current configuration, which is as simple as it can be but
no simpler, users run into weird problems which are hard to identify
and to correct.

> What if we would "rebrand" the current version as slf4j-api-jdk14 and
> call the formerly slf4j-api-jdk15 slf4j-api instead, obviously while
> increasing the version number to something like 2.0.0 to show that
> something has changed?

You are assuming that the set of problems in such an upgrade is finite
and somehow controllable. I am assuming the contrary. If SLF4J had 100,
1000 or even 10000 users than the upgrade path you suggest would
probably work beautifully.  Assuming only 1 in every 1000 user
encountered a problem with the upgrade, then we would have to deal
with 10 angry users.  Unpleasant but doable.  When you have a higher
number of users, say 100'000, and 100 of them get angry, they start to
feed off each other's anger and start calling names.

> Please forgive my insistence on these two RFE's, I just desperately
> try to find the perfect way to get varargs and
> param-logging+throwable into slf4j in a harmless fashion,
> i.e. causing no or nearly no problems.  I soooo want to use it like
> that :)

The *perfect* solution to the library versioning problem is much larger than
SLF4J's scope. :-)


-- 
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the slf4j-dev mailing list