Re: [slf4j-user] Java 5 version of SLF4J?
Simon Kitching wrote: > A push is quick, and cleaning up a callstack afterwards is normally done in > fixed-time, regardless of what was on the stack. If params are passed in > registers, it is even quicker. So IMO, SLF4J's approach is fine from a > performance approach. Sorry if my mail wasn't clear on that. > > IMO, creating the Object[] is worth avoiding, however, which rules out real > varargs implemetations [1]. The cost is not just creating, but also > garbage-collection afterwards. Yes, that is true but negligible as well. Newer JVM's (I believe starting from JSE5) will clean up shortly, or unused variables in fixed time as well. Objects can even be created on the call stack! Regards, Erik. ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
Hi Simon,
Comments below.
Simon Kitching wrote:
> Creating an object[] *after* the decision to log is made is no big
> deal. The overheads of actually logging a message are much higher, so
> passing the params is no longer significant. Only when one is created
> *regardless* of whether logging occurs is there an issue.
+1
> And BTW, I do agree with Ceki that pushing a couple of arguments
> onto the stack is not a big deal. A push is quick, and cleaning up a
> callstack afterwards is normally done in fixed-time, regardless of
> what was on the stack. If params are passed in registers, it is even
> quicker. So IMO, SLF4J's approach is fine from a performance
> approach. Sorry if my mail wasn't clear on that.
+1
> IMO, creating the Object[] is worth avoiding, however, which rules
> out real varargs implemetations [1]. The cost is not just creating,
> but also garbage-collection afterwards. Ceki and others made great
> efforts to get the original log4j performance up (see the original
> log4j page) and I'm sure he has put the same effort into logback. It
> seems a shame to waste that unless the user benefits are significant..
I agree with the above. It is probably useful to note that Joern's
patch [1], does not change the existing method signatures, with one
exception.
BEFORE:
public interface Logger {
public void debug(String msg);
public void debug(String format, Object arg);
public void debug(String format, Object arg1, Object arg2);
public void debug(String format, Object[] argArray);
public void debug(String msg, Throwable t);
... etc
}
After applying Joern's patch:
public interface Logger {
public void debug(String msg); // no change
public void debug(String format, Object arg); // no change
public void debug(String format, Object arg1, Object arg2); // no change
public void debug(String format, Object... argArray); // CHANGE
public void debug(String msg, Throwable t); // no change
... etc
}
Thus, Joern's patch has no impact on performance at all (compared to
SLF4J's Logger as it exists today).
> The best solution of all is probably some kind of code-weaving, eg
> http://just4log.sourceforge.net/ at build-time, or something similar
> at runtime. Then projects can use any kind of API they want.
Most developers I know, including myself, hate magic. They/I consider
byte code manipulation as magic. That's the perception. I can't
imagine anyone accepting to see their .class files to be
post-processed just for log (pun intended).
So while just4log addresses an existing problem, its remedy may be
*perceived* to be worse that the illness.
> [1] Unless the jvm is doing "escape analysis" as mentioned earlier
> in this thread. I wonder how we could find out?
> Simon
Interesting question. Don't have an answer.
Cheers,
[1] http://bugzilla.slf4j.org/attachment.cgi?id=21
--
Ceki Gülcü
QOS.ch is looking to hire talented developers in Switzerland. If
interested, please contact c e k i AT q o s . c h
___
user mailing list
user@slf4j.org
http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
Joern Huxhorn schrieb: > > Ceki Gulcu wrote: > > > >> >> Joern Huxhorn wrote: >> >> >> >>> >>> Simon Kitching wrote: >>> >>> >>> The SLF4J fake-varargs approach, where the api allows 0,1 or 2 params is slightly better, as it avoids the "new Object[]" call. But for best performance, isDebugEnabled should be used anyway. Regards, Simon >>> >>> Hi Simon. >>> >>> >>> >>> The above isn't the case for logback since calls with explicit >>> >>> arguments >>> >>> (instead of argument array) are simply wrapped in an Object[] and >>> >>> forwarded to the Object[]-implementation of the method. >>> >>> >>> >>> Joern. >>> >>> >>> >> >> Hello Joern, Hello Simon, >> >> >> >> >> >> I just quickly looked at the code and I believe that parameters are >> >> aggregated into Object[] *after* a decision is made to log. Filters in >> >> appenders may override this decision, but that happens much later in >> >> the processing pipeline. >> >> >> >> As for Simon's argument that the extra parameters need to be pushed >> >> onto the execution stack, I think that pushing one or two arguments >> >> onto the stack takes about or less than a nanosecond on most machines, >> >> hardly noticeable even if you log millions of times a second. >> >> Creating an Object[] takes about 20 nanoseconds, a lot more than >> >> pushing a parameter but still only 20 nanoseconds. >> >> >> >> Cheers, >> >> >> >> >> > > > > Hi Ceki. > > > > I didn't mean to imply that anything is wrong or inefficient with the > > current implementation in Logback. I only meant that an Object[] *is* > > created after the decision if logging should actually happen - which is > > absolutely necessary anyway because LoggingEvent needs the parameters in > > an Object[] anyway. > > > > It's just not the case - and I thought that's what Simon was thinking - > > that there is a special, optimized version of the logging methods that > > do not use an Object[] at all. > > > Creating an object[] *after* the decision to log is made is no big deal. The overheads of actually logging a message are much higher, so passing the params is no longer significant. Only when one is created *regardless* of whether logging occurs is there an issue. And BTW, I do agree with Ceki that pushing a couple of arguments onto the stack is not a big deal. A push is quick, and cleaning up a callstack afterwards is normally done in fixed-time, regardless of what was on the stack. If params are passed in registers, it is even quicker. So IMO, SLF4J's approach is fine from a performance approach. Sorry if my mail wasn't clear on that. IMO, creating the Object[] is worth avoiding, however, which rules out real varargs implemetations [1]. The cost is not just creating, but also garbage-collection afterwards. Ceki and others made great efforts to get the original log4j performance up (see the original log4j page) and I'm sure he has put the same effort into logback. It seems a shame to waste that unless the user benefits are significant.. The best solution of all is probably some kind of code-weaving, eg http://just4log.sourceforge.net/ at build-time, or something similar at runtime. Then projects can use any kind of API they want. [1] Unless the jvm is doing "escape analysis" as mentioned earlier in this thread. I wonder how we could find out? Regards, Simon ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
Ceki Gulcu wrote: > > Joern Huxhorn wrote: >> Simon Kitching wrote: >>> The SLF4J fake-varargs approach, where the api allows 0,1 or 2 params is >>> slightly better, as it avoids the "new Object[]" call. But for best >>> performance, isDebugEnabled should be used anyway. >>> >>> Regards, >>> Simon >> Hi Simon. >> >> The above isn't the case for logback since calls with explicit arguments >> (instead of argument array) are simply wrapped in an Object[] and >> forwarded to the Object[]-implementation of the method. >> >> Joern. > > Hello Joern, Hello Simon, > > > I just quickly looked at the code and I believe that parameters are > aggregated into Object[] *after* a decision is made to log. Filters in > appenders may override this decision, but that happens much later in > the processing pipeline. > > As for Simon's argument that the extra parameters need to be pushed > onto the execution stack, I think that pushing one or two arguments > onto the stack takes about or less than a nanosecond on most machines, > hardly noticeable even if you log millions of times a second. > Creating an Object[] takes about 20 nanoseconds, a lot more than > pushing a parameter but still only 20 nanoseconds. > > Cheers, > Hi Ceki. I didn't mean to imply that anything is wrong or inefficient with the current implementation in Logback. I only meant that an Object[] *is* created after the decision if logging should actually happen - which is absolutely necessary anyway because LoggingEvent needs the parameters in an Object[] anyway. It's just not the case - and I thought that's what Simon was thinking - that there is a special, optimized version of the logging methods that do not use an Object[] at all. Joern. ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
Joern Huxhorn wrote: > Simon Kitching wrote: >> The SLF4J fake-varargs approach, where the api allows 0,1 or 2 params is >> slightly better, as it avoids the "new Object[]" call. But for best >> performance, isDebugEnabled should be used anyway. >> >> Regards, >> Simon > > Hi Simon. > > The above isn't the case for logback since calls with explicit arguments > (instead of argument array) are simply wrapped in an Object[] and > forwarded to the Object[]-implementation of the method. > > Joern. Hello Joern, Hello Simon, I just quickly looked at the code and I believe that parameters are aggregated into Object[] *after* a decision is made to log. Filters in appenders may override this decision, but that happens much later in the processing pipeline. As for Simon's argument that the extra parameters need to be pushed onto the execution stack, I think that pushing one or two arguments onto the stack takes about or less than a nanosecond on most machines, hardly noticeable even if you log millions of times a second. Creating an Object[] takes about 20 nanoseconds, a lot more than pushing a parameter but still only 20 nanoseconds. Cheers, -- Ceki Gülcü QOS.ch is looking to hire talented developers in Switzerland. If interested, please contact c e k i AT q o s . c h ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
Hi Simon,
What you describe under [1] is called escape analysis. Under most
circumstances most code and most data is unused. This can be detected,
and some compilers actually do this. As I said, I am not sure the JVM is
capable of doing this. BTW, a runtime compiler such as hotspot has many
more options to do escape analysis then a static compiler.
> That would be seriously smart optimisation though.
I think you underestimate the cleverness of the JVM people :)
Apart from the potential performance penalty, I still think log5j has a
nicer interface. I would use it if was available for slf4j.
> I think the lack of varargs support is a feature, and good api design.
Well, I certainly do not agree there. But anyway, there are enough other
reasons for not changing the slf4j interface.
Regards,
Erik.
Simon Kitching wrote:
> Hi Erik,
>
> You're right that the correspondence between bytecode and actual machine
> instructions is not direct. And in fact, the machine instructions
> could even vary during a program's run if the JVM is doing dynamic
> optimisation.
>
> But in this specific case,
> (a) Whether the formatting parameters are used or not depends upon the
> current setting of the logging threshold level for that category. There
> is no way the caller can determine that, so AFAICT the params will
> really have to be passed somehow. [1]
> (b) If the params are used, then they are passed as an object array to
> java.util.Formatter so an object array does need to be created at that
> point. *Possibly* a clever runtime optimiser could pass the params in
> registers, and delay creating of the object array until after the
> threshold test is done. That would be seriously smart optimisation
> though. For a start, doing this means changing the way that callers
> invoke the method, so would need to dynamically be patched into every
> callsite, not just optimise the internal implementation of a method. And
> different Logger objects can theoretically have different concrete
> implementations at runtime, so the mechanism used to invoke the call
> would need to vary depending upon the concrete implementation
> referenced. I can't see that being feasable.
>
> [1] Unless the runtime optimiser sees that the first thing the called
> method does is invoke isXXXEnabled, before using any params. When the
> calling site is using a final reference to the logger object, it would
> then be possible to migrate that call up into the calling site, and the
> effect would be like wrapping every call in isXXXEnabled, which would be
> nice. I have no idea whether any existing JVMs do this; it's fairly
> clever work. Hmm.. it would also mean presumably rewriting the called
> method so that the isXXXEnabled does not get called multiple times. But
> that would then break other callers. Ouch, this makes my head hurt :-)
>
> I'd be willing to bet that in everything except specialist jvms (and
> maybe there too), the log5j approach has a significant performance
> penalty due to the creation of an object array for each call, and
> therefore manually wrapping in isXXXEnabled is needed.
>
> But
>// standard SLF4J or JCL
>if (log.isDebugEnabled())
> log.debug(String.format("...", arg1, arg2, arg3, arg4));
> and
>// log5j only
>if (log.isDebugEnabled())
> log.debug("...", arg1, arg2, arg3, arg4);
> are identical in performance, and not much different aesthetically.
>
> The mere existence of the varargs method, however, is a performance trap
> just waiting for users to fall into, tempting them to omit the
> isDebugEnabled call. A small trap, but nevertheless there. By *not*
> providing a varargs option, the SLF4J/JCL API instead makes it obvious
> that the isDebugEnabled is necessary. I think the lack of varargs
> support is a feature, and good api design.
>
> Regards,
>
> Simon
>
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
___
user mailing list
user@slf4j.org
http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
Hi Erik,
You're right that the correspondence between bytecode and actual machine
instructions is not direct. And in fact, the machine instructions
could even vary during a program's run if the JVM is doing dynamic
optimisation.
But in this specific case,
(a) Whether the formatting parameters are used or not depends upon the
current setting of the logging threshold level for that category. There
is no way the caller can determine that, so AFAICT the params will
really have to be passed somehow. [1]
(b) If the params are used, then they are passed as an object array to
java.util.Formatter so an object array does need to be created at that
point. *Possibly* a clever runtime optimiser could pass the params in
registers, and delay creating of the object array until after the
threshold test is done. That would be seriously smart optimisation
though. For a start, doing this means changing the way that callers
invoke the method, so would need to dynamically be patched into every
callsite, not just optimise the internal implementation of a method. And
different Logger objects can theoretically have different concrete
implementations at runtime, so the mechanism used to invoke the call
would need to vary depending upon the concrete implementation
referenced. I can't see that being feasable.
[1] Unless the runtime optimiser sees that the first thing the called
method does is invoke isXXXEnabled, before using any params. When the
calling site is using a final reference to the logger object, it would
then be possible to migrate that call up into the calling site, and the
effect would be like wrapping every call in isXXXEnabled, which would be
nice. I have no idea whether any existing JVMs do this; it's fairly
clever work. Hmm.. it would also mean presumably rewriting the called
method so that the isXXXEnabled does not get called multiple times. But
that would then break other callers. Ouch, this makes my head hurt :-)
I'd be willing to bet that in everything except specialist jvms (and
maybe there too), the log5j approach has a significant performance
penalty due to the creation of an object array for each call, and
therefore manually wrapping in isXXXEnabled is needed.
But
// standard SLF4J or JCL
if (log.isDebugEnabled())
log.debug(String.format("...", arg1, arg2, arg3, arg4));
and
// log5j only
if (log.isDebugEnabled())
log.debug("...", arg1, arg2, arg3, arg4);
are identical in performance, and not much different aesthetically.
The mere existence of the varargs method, however, is a performance trap
just waiting for users to fall into, tempting them to omit the
isDebugEnabled call. A small trap, but nevertheless there. By *not*
providing a varargs option, the SLF4J/JCL API instead makes it obvious
that the isDebugEnabled is necessary. I think the lack of varargs
support is a feature, and good api design.
Regards,
Simon
Erik van Oosten schrieb:
> Hi Simon,
>
> You should never confuse Java byte code with compiled byte code. I
> understand there are a few superfluous byte codes, but in the end the
> JVM determines how to compile it to CPU instructions. Unfortunately I am
> not aware of what the JVM actually does with unused values. Does it do
> escape analysis already?
>
> Regards,
> Erik.
>
>
> Simon Kitching schreef:
>
>> Erik van Oosten schrieb:
>>
>>
>>> Christopher,
>>>
>>> As I wrote already on Feb 17:
>>> There is another aproach, as taken by http://code.google.com/p/log5j/.
>>> It is
>>> a wrapper around log4j. I wish they had made it for SLF4J!
>>>
>>> I am still waiting for someone to this for SLF4J. It should not be hard. I
>>> did not yet find the time myself :(
>>>
>>>
>>>
>> Sigh. Broken broken broken.
>>
>> Re the "feature" for determining which category to create a logger for,
>> see the documentation for Exception.getStackTrace. There is no guarantee
>> that valid info about the callstack is available. So this code will work
>> fine under unit testing, then may start emitting messages to the wrong
>> categories when run in a high-performance environment. That will be fun
>> to debug...
>>
>> Re the printf-style formatting:
>>
>> log.debug("format str", arg0, arg1, arg2);
>>
>> is exactly equivalent to:
>>
>> push "format str" onto stack
>> tmp = new Object[3];
>> tmp[0] = arg0;
>> tmp[1] = arg1;
>> tmp[2] = arg2;
>> push tmp onto stack
>> invoke log.debug
>> (and of course garbage-collect the tmp object later..)
>>
>> So in practice, for good performance you need
>> if (log.isDebugEnabled())
>> around each call anyway. In which case, the printf-style stuff gives no
>> performance benefits at all; if something is going to be logged then the
>> formatting is nowhere near the bottleneck step.
>>
>> The SLF4J fake-varargs approach, where the api allows 0,1 or 2 params is
>> slightly better, as it avoids the "new Object[]" call. But for best
>> performance, isDebugEnabled should be used anyway.
>>
>> Regards,
>>
Re: [slf4j-user] Java 5 version of SLF4J?
Hi Simon,
You should never confuse Java byte code with compiled byte code. I
understand there are a few superfluous byte codes, but in the end the
JVM determines how to compile it to CPU instructions. Unfortunately I am
not aware of what the JVM actually does with unused values. Does it do
escape analysis already?
Regards,
Erik.
Simon Kitching schreef:
> Erik van Oosten schrieb:
>
>> Christopher,
>>
>> As I wrote already on Feb 17:
>> There is another aproach, as taken by http://code.google.com/p/log5j/.
>> It is
>> a wrapper around log4j. I wish they had made it for SLF4J!
>>
>> I am still waiting for someone to this for SLF4J. It should not be hard. I
>> did not yet find the time myself :(
>>
>>
>
> Sigh. Broken broken broken.
>
> Re the "feature" for determining which category to create a logger for,
> see the documentation for Exception.getStackTrace. There is no guarantee
> that valid info about the callstack is available. So this code will work
> fine under unit testing, then may start emitting messages to the wrong
> categories when run in a high-performance environment. That will be fun
> to debug...
>
> Re the printf-style formatting:
>
> log.debug("format str", arg0, arg1, arg2);
>
> is exactly equivalent to:
>
> push "format str" onto stack
> tmp = new Object[3];
> tmp[0] = arg0;
> tmp[1] = arg1;
> tmp[2] = arg2;
> push tmp onto stack
> invoke log.debug
> (and of course garbage-collect the tmp object later..)
>
> So in practice, for good performance you need
> if (log.isDebugEnabled())
> around each call anyway. In which case, the printf-style stuff gives no
> performance benefits at all; if something is going to be logged then the
> formatting is nowhere near the bottleneck step.
>
> The SLF4J fake-varargs approach, where the api allows 0,1 or 2 params is
> slightly better, as it avoids the "new Object[]" call. But for best
> performance, isDebugEnabled should be used anyway.
>
> Regards,
> Simon
>
> ___
> user mailing list
> user@slf4j.org
> http://www.slf4j.org/mailman/listinfo/user
>
--
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
___
user mailing list
user@slf4j.org
http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
[EMAIL PROTECTED] wrote:
> It's nice to see that you were on top of this already.
>
> My only issue with your fix is that it can be ambiguous as to which comes
> first (params or exception). I'd much prefer putting the exception at the
> front of the method signature (as was suggested by another user in either
> this or the Logback mailing list)
>
> i.e. error(Throwable t, String msg, Object params...)
>
> This makes it much more clear where the exception should be placed. And,
> like what was said by the other user, you could also optionally put the
> exception into the message as a parameter without casting.
This would break compatibility with the current API which is a
definitive no-no.
A Throwable as the last argument, however, will only be used as a
Throwable instead of just a String if there are not enough {} parameters
in the message. You could even have both if you add the Throwable twice.
I can also attest based, on experience, that people actually expect the
exception as the last parameter.
What I mean with experience is that all the mistakenly added exceptions
(which are silently swallowed at the moment if there's no {} left in the
message string) in our company were mistakenly placed at that position,
i.e. as the last argument.
I think this happened once or twice to *every* developer in our team...
Joern.
___
user mailing list
user@slf4j.org
http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
Hi Joern, Christopher White's sums the warts in the SLF4J API pretty well: I did know that I can parameterize up to 2 parameters, which is nice. But I also think that it is annoying to have to remember to change the syntax once you hit 3+ parameters. Along with this, it is also annoying to have to remember to change syntax when logging errors (cannot use paramatized strings). It would be nice if things were more consistent. Your patch for bug 31 is pretty nice and is probably the best that can be done under the circumstances. However, it would force our users to *think* about what the implications of using slf4j-api-jdk15. Developers are sick and tired of dealing with logging related issues in their projects. For example, a few months ago the Apache Directory project had an animated debate on why logging was so darn complicated. Such debates occur frequently in various mailing lists. One of the reasons SLF4J exists, is to make life easier for developers. It would not be wise to introduce a new level of complexity on account of two near-equivalent SLF4J-API artifacts. Simon could probably attest that as far logging is concerned, even the slightest complexity takes on frightening proportions. Joern Huxhorn wrote: > Hi guys. > > My patch available at http://bugzilla.slf4j.org/show_bug.cgi?id=31 > supports varargs without changing the slf4j API at all. > > It would be included in maven like this > > > org.slf4j > slf4j-api-jdk15 > 1.5.0 > compile > > > > org.slf4j > slf4j-api > 1.5.0 > provided > > > > It is possible that > > org.slf4j > slf4j-api-jdk15 > 1.5.0 > compile > > > org.slf4j > slf4j-api > > > > would work, too, but I never tried that... > > slf4j-api-jdk15 is an *additional* artifact that contains the slf4j API > using varargs instead of Object[]. > > That's why slf4j-api is *not* changed/polluted at all! > > Modules/libraries compiled against slf4j-api will just work with > slf4j-api-jdk15. > > Obviously, the opposite is not the case: > > Modules/libraries compiled against slf4j-api-jdk15 will require > slf4j-api-jdk15 and can not be switched back to slf4j-api because they > use jdk15 specific code. > I can't see *any* problem with this fact since, well, they are jdk15 > dependent - otherwise they couldn't (slf4j-api-jdk15 *requires* jdk15) > and wouldn't (you don't *have* to use slf4j-api-jdk15 if you use > jdk15... you can still use slf4j-api if you don't care about varargs) > use slf4j-api-jdk15. > > Greetings, > Joern. -- Ceki Gülcü QOS.ch is looking to hire talented developers in Switzerland. If interested, please contact c e k i AT q o s . c h ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
It's nice to see that you were on top of this already.
My only issue with your fix is that it can be ambiguous as to which comes
first (params or exception). I'd much prefer putting the exception at the
front of the method signature (as was suggested by another user in either
this or the Logback mailing list)
i.e. error(Throwable t, String msg, Object params...)
This makes it much more clear where the exception should be placed. And,
like what was said by the other user, you could also optionally put the
exception into the message as a parameter without casting.
Thanks,
Christopher White
Sr. Programmer
1-617-772-2403
[EMAIL PROTECTED]
Joern Huxhorn <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
04/24/2008 10:24 AM
Please respond to
User list for the slf4j project
To
User list for the slf4j project
cc
Subject
Re: [slf4j-user] Java 5 version of SLF4J?
[EMAIL PROTECTED] wrote:
> I did know that I can parameterize up to 2 parameters, which is nice.
But
> I also think that it is annoying to have to remember to change the
syntax
> once you hit 3+ parameters. Along with this, it is also annoying to have
> to remember to change syntax when logging errors (cannot use paramatized
> strings). It would be nice if things were more consistent.
>
> -Chris
I agree 100%.
Please take a look at http://bugzilla.slf4j.org/show_bug.cgi?id=70
Those are IMO the only two downsides of slf4j/logback...
Joern.
___
user mailing list
user@slf4j.org
http://www.slf4j.org/mailman/listinfo/user
*** 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.
___
user mailing list
user@slf4j.org
http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
[EMAIL PROTECTED] wrote: > I did know that I can parameterize up to 2 parameters, which is nice. But > I also think that it is annoying to have to remember to change the syntax > once you hit 3+ parameters. Along with this, it is also annoying to have > to remember to change syntax when logging errors (cannot use paramatized > strings). It would be nice if things were more consistent. > > -Chris I agree 100%. Please take a look at http://bugzilla.slf4j.org/show_bug.cgi?id=70 Those are IMO the only two downsides of slf4j/logback... Joern. ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
Simon Kitching wrote: > The SLF4J fake-varargs approach, where the api allows 0,1 or 2 params is > slightly better, as it avoids the "new Object[]" call. But for best > performance, isDebugEnabled should be used anyway. > > Regards, > Simon Hi Simon. The above isn't the case for logback since calls with explicit arguments (instead of argument array) are simply wrapped in an Object[] and forwarded to the Object[]-implementation of the method. Joern. ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
I did know that I can parameterize up to 2 parameters, which is nice. But
I also think that it is annoying to have to remember to change the syntax
once you hit 3+ parameters. Along with this, it is also annoying to have
to remember to change syntax when logging errors (cannot use paramatized
strings). It would be nice if things were more consistent.
-Chris
Thanks,
Christopher White
Sr. Programmer
1-617-772-2403
[EMAIL PROTECTED]
Ceki Gulcu <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
04/24/2008 09:51 AM
Please respond to
User list for the slf4j project
To
User list for the slf4j project
cc
Subject
Re: [slf4j-user] Java 5 version of SLF4J?
[EMAIL PROTECTED] wrote:
>
> Ceki,
>
> I do understand your reasoning, and thank you for your quick response.
>
> 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)?
Correct. As you stated, the logback API sits on top of SLF4J. There are no
plans
to change that.
> 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).
You do realize that the SLF4J API already supports parameterized logging
up to 2
parameters? With an SLF4J logger you can write:
Logger logger = LoggerFactory.getLogger(Wombat.class);
Integer t;
Integer oldT;
Integer expectedT;
logger.debug("Some message.");
logger.debug("Temperature set to {}", t);
logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);
However, SLF4J does not support 3 or more parameters. So, you could not
write:
logger.debug("new={}, old={}, expected={}", t, oldT, expectedT);
You would have to write:
logger.debug("new={}, old={}, expected={}", new Integer[] {t, oldT,
expectedT});
I believe that compared to the slight inconvenience above, breaking
compatibility is a more serious concern.
> 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.
You might also want to check out the slf4j-migrator [1] which may help
with your
migration efforts, when and if you decide to migrate to SLF4J.
[1] http://slf4j.org/migrator.html
--
Ceki Gülcü
QOS.ch is looking to hire talented developers in Switzerland. If
interested, please contact c e k i AT q o s . c h
___
user mailing list
user@slf4j.org
http://www.slf4j.org/mailman/listinfo/user
*** 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.
___
user mailing list
user@slf4j.org
http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
Hi guys. My patch available at http://bugzilla.slf4j.org/show_bug.cgi?id=31 supports varargs without changing the slf4j API at all. It would be included in maven like this org.slf4j slf4j-api-jdk15 1.5.0 compile org.slf4j slf4j-api 1.5.0 provided It is possible that org.slf4j slf4j-api-jdk15 1.5.0 compile org.slf4j slf4j-api would work, too, but I never tried that... slf4j-api-jdk15 is an *additional* artifact that contains the slf4j API using varargs instead of Object[]. That's why slf4j-api is *not* changed/polluted at all! Modules/libraries compiled against slf4j-api will just work with slf4j-api-jdk15. Obviously, the opposite is not the case: Modules/libraries compiled against slf4j-api-jdk15 will require slf4j-api-jdk15 and can not be switched back to slf4j-api because they use jdk15 specific code. I can't see *any* problem with this fact since, well, they are jdk15 dependent - otherwise they couldn't (slf4j-api-jdk15 *requires* jdk15) and wouldn't (you don't *have* to use slf4j-api-jdk15 if you use jdk15... you can still use slf4j-api if you don't care about varargs) use slf4j-api-jdk15. Greetings, Joern. Ceki Gulcu wrote: > Hello Christopher, > > Users keep asking for varagrs [1]. However, as I stated at the time, > given that SLF4J is intended used by all sorts of libraries, the > dependency graph between libraries and SLF4J can be surprisingly > complex. In particular, it would not be unusual for the dependency > graph to have multiple dependencies on SLF4J with *different* > versions. Thus, we have to be extra-careful and conservative when > changing the SLF4J API. > > I regret to disappoint our users but except for bug fixes, do not > expect any changes to the SLF4J API. > > [1] http://www.slf4j.org/pipermail/user/2008-January/000468.html > > > [EMAIL PROTECTED] wrote: >> Has there been any more discussion lately about updating the API to >> support varargs and perhaps printf? > > ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
Erik van Oosten schrieb:
> Christopher,
>
> As I wrote already on Feb 17:
> There is another aproach, as taken by http://code.google.com/p/log5j/.
> It is
> a wrapper around log4j. I wish they had made it for SLF4J!
>
> I am still waiting for someone to this for SLF4J. It should not be hard. I
> did not yet find the time myself :(
>
Sigh. Broken broken broken.
Re the "feature" for determining which category to create a logger for,
see the documentation for Exception.getStackTrace. There is no guarantee
that valid info about the callstack is available. So this code will work
fine under unit testing, then may start emitting messages to the wrong
categories when run in a high-performance environment. That will be fun
to debug...
Re the printf-style formatting:
log.debug("format str", arg0, arg1, arg2);
is exactly equivalent to:
push "format str" onto stack
tmp = new Object[3];
tmp[0] = arg0;
tmp[1] = arg1;
tmp[2] = arg2;
push tmp onto stack
invoke log.debug
(and of course garbage-collect the tmp object later..)
So in practice, for good performance you need
if (log.isDebugEnabled())
around each call anyway. In which case, the printf-style stuff gives no
performance benefits at all; if something is going to be logged then the
formatting is nowhere near the bottleneck step.
The SLF4J fake-varargs approach, where the api allows 0,1 or 2 params is
slightly better, as it avoids the "new Object[]" call. But for best
performance, isDebugEnabled should be used anyway.
Regards,
Simon
___
user mailing list
user@slf4j.org
http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
Yes Erick, I did see your earlier post. And while I do agree that such a
wrapper would be nice, I just wish we could stay away from such extras.
I'm not interested in more clutter/dependencies. I'd like to have the
logging API natively support these things.
-chris
Thanks,
Christopher White
Sr. Programmer
1-617-772-2403
[EMAIL PROTECTED]
Erik van Oosten <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
04/24/2008 09:50 AM
Please respond to
User list for the slf4j project
To
User list for the slf4j project
cc
Subject
Re: [slf4j-user] Java 5 version of SLF4J?
Christopher,
As I wrote already on Feb 17:
There is another aproach, as taken by
http://code.google.com/p/log5j/. It is
a wrapper around log4j. I wish they had made it for
SLF4J!
I am still waiting for someone to this for SLF4J. It should not be hard. I
did not yet find the time myself :(
Regards,
Erik.
[EMAIL PROTECTED] wrote:
>
> Ceki,
>
> I do understand your reasoning, and thank you for your quick response.
>
>
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
___
user mailing list
user@slf4j.org
http://www.slf4j.org/mailman/listinfo/user
*** 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.
___
user mailing list
user@slf4j.org
http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
[EMAIL PROTECTED] wrote:
>
> Ceki,
>
> I do understand your reasoning, and thank you for your quick response.
>
> 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)?
Correct. As you stated, the logback API sits on top of SLF4J. There are no
plans
to change that.
> 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).
You do realize that the SLF4J API already supports parameterized logging up to
2
parameters? With an SLF4J logger you can write:
Logger logger = LoggerFactory.getLogger(Wombat.class);
Integer t;
Integer oldT;
Integer expectedT;
logger.debug("Some message.");
logger.debug("Temperature set to {}", t);
logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);
However, SLF4J does not support 3 or more parameters. So, you could not write:
logger.debug("new={}, old={}, expected={}", t, oldT, expectedT);
You would have to write:
logger.debug("new={}, old={}, expected={}", new Integer[] {t, oldT, expectedT});
I believe that compared to the slight inconvenience above, breaking
compatibility is a more serious concern.
> 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.
You might also want to check out the slf4j-migrator [1] which may help with
your
migration efforts, when and if you decide to migrate to SLF4J.
[1] http://slf4j.org/migrator.html
--
Ceki Gülcü
QOS.ch is looking to hire talented developers in Switzerland. If
interested, please contact c e k i AT q o s . c h
___
user mailing list
user@slf4j.org
http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
Christopher, As I wrote already on Feb 17: There is another aproach, as taken by http://code.google.com/p/log5j/. It is a wrapper around log4j. I wish they had made it for SLF4J! I am still waiting for someone to this for SLF4J. It should not be hard. I did not yet find the time myself :( Regards, Erik. [EMAIL PROTECTED] wrote: > > Ceki, > > I do understand your reasoning, and thank you for your quick response. > > -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
Ceki,
I do understand your reasoning, and thank you for your quick response.
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)?
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).
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.
-Chris
Ceki Gulcu <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
04/24/2008 08:46 AM
Please respond to
User list for the slf4j project
To
User list for the slf4j project
cc
Subject
Re: [slf4j-user] Java 5 version of SLF4J?
Hello Christopher,
Users keep asking for varagrs [1]. However, as I stated at the time,
given that SLF4J is intended used by all sorts of libraries, the
dependency graph between libraries and SLF4J can be surprisingly
complex. In particular, it would not be unusual for the dependency
graph to have multiple dependencies on SLF4J with *different*
versions. Thus, we have to be extra-careful and conservative when
changing the SLF4J API.
I regret to disappoint our users but except for bug fixes, do not
expect any changes to the SLF4J API.
[1] http://www.slf4j.org/pipermail/user/2008-January/000468.html
[EMAIL PROTECTED] wrote:
>
> Has there been any more discussion lately about updating the API to
> support varargs and perhaps printf?
--
Ceki Gülcü
QOS.ch is looking to hire talented developers in Switzerland. If
interested, please contact c e k i AT q o s . c h
___
user mailing list
user@slf4j.org
http://www.slf4j.org/mailman/listinfo/user
*** 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.
___
user mailing list
user@slf4j.org
http://www.slf4j.org/mailman/listinfo/user
Re: [slf4j-user] Java 5 version of SLF4J?
Hello Christopher, Users keep asking for varagrs [1]. However, as I stated at the time, given that SLF4J is intended used by all sorts of libraries, the dependency graph between libraries and SLF4J can be surprisingly complex. In particular, it would not be unusual for the dependency graph to have multiple dependencies on SLF4J with *different* versions. Thus, we have to be extra-careful and conservative when changing the SLF4J API. I regret to disappoint our users but except for bug fixes, do not expect any changes to the SLF4J API. [1] http://www.slf4j.org/pipermail/user/2008-January/000468.html [EMAIL PROTECTED] wrote: > > Has there been any more discussion lately about updating the API to > support varargs and perhaps printf? -- Ceki Gülcü QOS.ch is looking to hire talented developers in Switzerland. If interested, please contact c e k i AT q o s . c h ___ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
