<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 08.03.2010, at 15:34, Ceki Gülcü wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On 08/03/2010 2:49 PM, Joern Huxhorn wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">That's not entirely true.<br></blockquote><blockquote type="cite">As you stated in that comment, compatibility is not the case if someone<br></blockquote><blockquote type="cite">compiles against SLF4J v2 (with varargs) but the container uses JDK 1.4.<br></blockquote><blockquote type="cite"><a href="http://bugzilla.slf4j.org/show_bug.cgi?id=31#c75">http://bugzilla.slf4j.org/show_bug.cgi?id=31#c75</a><br></blockquote><blockquote type="cite">I fear that SLF4J v2 might sneak up on some people by either not RTFM of<br></blockquote><blockquote type="cite">SLF4J v2 or by some dependency where the developers did not RTFM the<br></blockquote><blockquote type="cite">SLF4J v2 manual.<br></blockquote><blockquote type="cite">It wouldn't be our fault in both cases but it would boil down to<br></blockquote><blockquote type="cite">"Updating xyz broke my build" subjects in mailinglists with the<br></blockquote><blockquote type="cite">explanation that it was because of the SLF4J dependency.<br></blockquote><br>But that's OK isn't it? If project A is built under JDK 1.4, upgrading<br>to SLF4J v2 would result in an incompatible class version during the<br>build and the developer will be forced to stay with slf4j 1.5.x, which<br>is OK.<br><br>Moreover, while a container may be built using JDK 1.4 I don't see how<br>a container could force the use of JDK 1.4. The end-user can always<br>chose to use a later version of the JDK.<br><br>My comment was about a container exporting its version of SLF4J to the<br>application, but as long as SLF4J v1 and v2 are binary compatible that<br>would not be a problem. If v1 and v2 are NOT binary compatible, then that's<br>a different matter altogether.<br></div></blockquote><div><br></div><div>It's just that AFAIK Websphere requires a certain JRE.</div><div>I've no personal experience with it, though (thankfully!)...</div><div><br></div><blockquote type="cite"><div><blockquote type="cite"><font class="Apple-style-span" color="#000000"><br></font></blockquote><blockquote type="cite">Lots of people switched their codebase over to SLF4J by a simple search<br></blockquote><blockquote type="cite">&amp; destroy, I guess.<br></blockquote><br>Search and replace, not destroy. :-)<br></div></blockquote><div><br></div><div>Yes, indeed ;)</div><br><blockquote type="cite"><div><br><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">It's a shame that there's no tool to analyze the whole central Maven2<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">repository concerning this, or is there?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">It would be great if there was a way to find out which modules depend on<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">SLF4J (either directly or transitively) and are still 1.4.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Let's google it. :-)<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Did you succeed?<br></blockquote><br>No, that's was my feeble attepmt at cracking a joke.<br></div></blockquote><div><br></div><div>There goes my hope ;)</div><br><blockquote type="cite"><div><br><blockquote type="cite"><blockquote type="cite">If we are going to re-implement org.slf4j.Logger under<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">org.slf4j.n.Logger, we might as well call it org.newslf4j.Logger and<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">start over from scratch. Copying the API to new packages avoids<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">conflicts but otherwise constitutes a radical break.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Yes, it does. But it also cleans up the API and adds some very<br></blockquote><blockquote type="cite">substantial features.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">There are lots of methods that aren't necessary anymore with varargs and<br></blockquote><blockquote type="cite">exception support built in.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Additional ones would be extremely nice to have.<br></blockquote><blockquote type="cite">Methods supporting the (or a) Message interface would enable the user to<br></blockquote><blockquote type="cite">define his own application-specific message implementation which would<br></blockquote><blockquote type="cite">bring a whole new level to the framework. He could access those special<br></blockquote><blockquote type="cite">messages without parsing in specifically written appenders.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I've also added log(Level,....) and isEnabled(Level[,Marker])-methods<br></blockquote><blockquote type="cite">for cases where the actual level a call uses is determined<br></blockquote><blockquote type="cite">programmatically.<br></blockquote><blockquote type="cite">This is something that we needed on several occasions, too.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">But additional methods can't be added to the original SLF4J because, as<br></blockquote><blockquote type="cite">you correctly enforce, SLF4J API is frozen and must stay that way.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">What I suggest is a bit like the junit package switch. With JUnit 4 the<br></blockquote><blockquote type="cite">package changed from junit to org.junit. The original junit keeps<br></blockquote><blockquote type="cite">working as before but new stuff was added in org.junit.<br></blockquote><br>Good point. There are several differences between the Junit case and SLF4J. Junit3 had maybe 99% market share of the unit testing API "market". The market shared being eroded by TestNG which brought in annotations as significant improvement over Junit3. I don't think Junit4 would exist without TestNG competitive pressure.<br><br>As far as I know, SLF4J has no competition from a "feature" point of view. Of course, there is JCL, jul and log4j but they all have less advanced user-facing logging APIs.<br></div></blockquote><div><br></div><div>I can't argue against this, there's no real competitive pressure right now.</div><div><br></div><div>On the other hand, I think that this is somewhat caused by the fact that you are developing both SLF4J and Logback (which is IMHO the state of the art concerning logging) - meaning that there won't be pressure from that side.</div><div><br></div><div>Concerning features, JUL supports logging for a given level, e.g. log(Level level, String msg).</div><div>With SLF4J one has to (re)invent a level &nbsp;incl. code like</div><div>switch(level)</div><div>{</div><div>case DEBUG: logger.debug(...);</div><div>break;</div><div>[... etc.]</div><div>}</div><div><br></div><div>Instead of waiting for competition to appear (e.g. Log4J 2.0?), we should innovate anyway.</div><br><blockquote type="cite"><div><br><blockquote type="cite">You are right: the package could be named anything.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The only reasons I choose org.slf4j.n was<br></blockquote><blockquote type="cite">a) making a switch easy by just adding .n to import statements<br></blockquote><blockquote type="cite">b) using the SLF4J brand because it's established and people already<br></blockquote><blockquote type="cite">believe/put trust in it<br></blockquote><blockquote type="cite">c) it was merely a suggestion<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The main point, though, is, that there would be zero impact on any<br></blockquote><blockquote type="cite">existing code base. Everything, even SLF4J implementations, don't have<br></blockquote><blockquote type="cite">to do anything. The new API would be supported anyway.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">In case of JDK&gt;=1.5 implementations like Logback, it does make a lot of<br></blockquote><blockquote type="cite">sense to implement the new API directly (so the Message reaches the<br></blockquote><blockquote type="cite">appenders - instead of an String) and wrapping the other way around,<br></blockquote><blockquote type="cite">i.e. using a wrapper to support the original SLF4J API (which is already<br></blockquote><blockquote type="cite">provided in the new Logger interface via getOldLogger() method). But<br></blockquote><blockquote type="cite">this isn't required for org.slf4j.n to work.<br></blockquote><br>IMO, support for messages can be sufficiently important as to justify a<br>new API but I am not convinced yet.<br><br></div></blockquote><div><br></div><div>What would it take to convince you?</div><div><br></div><div>The addition of Message support would solve problems like the following in an unintrusive &nbsp;</div><div><a href="http://bugzilla.slf4j.org/show_bug.cgi?id=116">http://bugzilla.slf4j.org/show_bug.cgi?id=116</a> (java.util.Formatter support)</div><div><a href="http://bugzilla.slf4j.org/show_bug.cgi?id=148">http://bugzilla.slf4j.org/show_bug.cgi?id=148</a> (StructuredData support, RFC 5424)</div><div><a href="http://jira.qos.ch/browse/LBCLASSIC-76">http://jira.qos.ch/browse/LBCLASSIC-76</a> (Allow extension of LoggingEvent with new data)</div><div><br></div><div>Also, the Message instance might be used in Logback TurboFilters, I think.</div><div>It may be necessary to change the interface (or at least the implementation of ParameterizedMessage) a bit for better performance, i.e. deferring the evaluation (searching for Throwable) and transformation of the argument[]&nbsp;into a String[] until after the TurboFilter. (Yes, I know, that's a Logback-only issue)</div><br><blockquote type="cite"><div>By the way, the invitation made to Juergen regarding a link at a<br>prominent place on the SLF4J web-site extends to your fork as<br>well. I'll gladly add a link to<br><a href="http://github.com/huxi/slf4j/tree/slf4j-redesign">http://github.com/huxi/slf4j/tree/slf4j-redesign</a> with a description<br>provided by you so that can people can try it out and provide<br>feedback.<br></div></blockquote><div><blockquote type="cite"><div><br>WDYT?<br></div></blockquote><br></div><div>I'd have no problem with that, though I'm not sure if I'll be able to keep that branch updated with the main SLF4J branch.</div><div>The main problem I see is that it's not worth that much without Logback supporting it. It's nice to have the Messages but a lot of power is lost if the appenders in Logback are still getting an event containing a formatted message string. Ralph couldn't use the StructuredData without parsing it first, for example.</div></div><br><div>Cheers,</div><div>Joern.</div></body></html>