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?
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?
[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?
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 user@slf4j.org To User list for the slf4j project user@slf4j.org 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?
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 user@slf4j.org
To
User list for the slf4j project user@slf4j.org
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?
[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?
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 user@slf4j.org To User list for the slf4j project user@slf4j.org 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?
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 dependency groupIdorg.slf4j/groupId artifactIdslf4j-api-jdk15/artifactId version1.5.0/version scopecompile/scope !-- replacement for slf4j-api below -- /dependency dependency groupIdorg.slf4j/groupId artifactIdslf4j-api/artifactId version1.5.0/version scopeprovided/scope !-- overrides transitive dependencies, replaced by slf4j-api-jdk15 above -- /dependency It is possible that dependency groupIdorg.slf4j/groupId artifactIdslf4j-api-jdk15/artifactId version1.5.0/version scopecompile/scope exclusions exclusion groupIdorg.slf4j/groupId artifactIdslf4j-api/artifactId /exclusion /exclusions /dependency 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?
[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
[slf4j-user] Java 5 version of SLF4J?
Has there been any more discussion lately about updating the API to support varargs and perhaps printf? *** 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
