<br><font size=2 face="sans-serif">Ceki,</font>
<br>
<br><font size=2 face="sans-serif">I do understand your reasoning, and
thank you for your quick response.</font>
<br>
<br><font size=2 face="sans-serif">And since Logback natively implements
SLF4J, its API will also not be changed to include any new JSE 5 features,
correct? Nor will new method signatures specific to just Logback be created
for this (if I chose to use Logback without SLF4J)?</font>
<br>
<br><font size=2 face="sans-serif">This is unfortunate for those who have
been using JSE 5 for some time now, and still have not been able to fully
take advantage of its features (especially when it comes to the work of
tedious logging). </font>
<br>
<br><font size=2 face="sans-serif">I was really excited about SLF4J/Logback
when this project started, but without these new features (which would
simplify and reduce my coding effort) it just doesn't seem worth it to
convert to this logging framework (even though I really appreciate the
clean Logback implementation). Perhaps Log4J 2.0 will incorporate these
considerations since it will be JSE 5 dependent. If it does, I'd have to
bet that many people will jump ship on SLF4J/Logback in favor of Log4J.
It really is too bad that the Logback API cannot be changed before it reaches
version 1.0.</font>
<br>
<br>
<br><font size=2 face="sans-serif"><br>
-Chris<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Ceki Gulcu <listid@qos.ch></b>
</font>
<br><font size=1 face="sans-serif">Sent by: user-bounces@slf4j.org</font>
<p><font size=1 face="sans-serif">04/24/2008 08:46 AM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
User list for the slf4j project <user@slf4j.org></font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">User list for the slf4j project <user@slf4j.org></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [slf4j-user] Java 5 version of SLF4J?</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt><br>
Hello Christopher,<br>
<br>
Users keep asking for varagrs [1]. However, as I stated at the time,<br>
given that SLF4J is intended used by all sorts of libraries, the<br>
dependency graph between libraries and SLF4J can be surprisingly<br>
complex. In particular, it would not be unusual for the dependency<br>
graph to have multiple dependencies on SLF4J with *different*<br>
versions. Thus, we have to be extra-careful and conservative when<br>
changing the SLF4J API.<br>
<br>
I regret to disappoint our users but except for bug fixes, do not<br>
expect any changes to the SLF4J API.<br>
<br>
[1] http://www.slf4j.org/pipermail/user/2008-January/000468.html<br>
<br>
<br>
Christopher.White@bbh.com wrote:<br>
> <br>
> Has there been any more discussion lately about updating the API to
<br>
> support varargs and perhaps printf?<br>
<br>
<br>
-- <br>
Ceki Gülcü<br>
QOS.ch is looking to hire talented developers in Switzerland. If<br>
interested, please contact c e k i AT q o s . c h<br>
<br>
_______________________________________________<br>
user mailing list<br>
user@slf4j.org<br>
http://www.slf4j.org/mailman/listinfo/user<br>
</tt></font>
<br>
<P><hr size=1></P><P><STRONG>*************************** IMPORTANT NOTE *****************************
The opinions expressed in this message and/or any attachments are those of the author and not necessarily those of Brown Brothers Harriman & Co., its subsidiaries and affiliates BBH. There is no guarantee that this message is either private or confidential, and it may have been altered by unauthorized sources without your or our knowledge. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. BBH accepts no responsibility for loss or damage from its use, including damage from virus. *******************************************************************</STRONG></P>