http://bugzilla.slf4j.org/show_bug.cgi?id=31
------- Comment #23 from [EMAIL PROTECTED] 2008-04-24 18:16 ------- Those are very valid points, especially the Geronimo one. 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? Since Geronimo requires JDK 1.5 it would be a mistake (more or less) to include slf4j-api instead of slf4j-api-jdk15, right? How about the opposite direction? 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? That way all dependent modules would "automatically" be updated to the varargs version of the API and modules using jdk14 could still use slf4j after changing the artifact to slf4j-api-jdk14. It's more or less common that newer versions of an API require newer JDK versions so something like this wouldn't be entirely unexpected. Keep in mind that you can only run into problems if something is compiled against the jdk15 version but the jdk14 version is on the classpath instead. So, in case of the Geronimo example, the correct version would be used just by upgrading the version number, which is bound to happen sooner or later anyway. I *think* this could eventually be the "right" solution... 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 :) I really appreciate the discussion and I can understand your hesitation... you are in charge of a widely used API, after all, so it wouldn't really help if something breaks horribly... btw, I never heard of NIH syndrome before... I must remember that one ;) -- 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
