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

[bugzilla-daemon at pixie.qos.ch]

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





------- Comment #22 from listid at qos.ch  2008-04-24 17:23 -------
I have read and re-read this report to ensure that I was not
succumbing to NIH syndrome. I think my position stated in comment #10,
dated 2007-10-10 21:27:12, is still relevant. Quoting:

 I think providing multiple versions of the API is too complicated as
 well as error prone. Logging has to be simple. As soon as one tries
 to be smart about logging, things start to crumble. (Simplicity and
 robustness is SLF4J's main selling point.)

 I appreciate your effort. [snip] Your solution produces
 two jars which need to be documented and installed separately. Most
 importantly, our user base has to be educated about it. Given the
 number of SLF4J users, that's too much of a hassle. After careful
 review of your proposal, although it has real merit, I am sorry to
 reject it.

As for the second proposal which changes the artifact id to
slf4j-api-jdk15, the problem of educating our users remains an issue.

Moreover, it is not hard to imagine cases where both slf4j-api and
slf4j-api-jdk15 would be present simultaneously in a project. For
example, let us assume that project P depends on D1 and D1. D1
depends on slf4j-api and D2 on slf4j-api-jdk15, causing a
conflict. Admittedly, this conflict could be avoided by excluding the
slfj-api dependency. But what would happen if the a J2EE container
exported SLF4J?

For instance, the Geronimo project just switched to SLF4J. What if
Geronimo exported slf4j-api while some application was expecting
slf4j-api-jdk15?


-- 
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.