http://bugzilla.slf4j.org/show_bug.cgi?id=31
------- Comment #24 from [EMAIL PROTECTED] 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. _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
