You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Peter Nann <pe...@vecommerce.com.au> on 2008/06/11 06:42:53 UTC
RE: log4j best practises - logger.isDebugEnabled()
I am only a peripheral Log4J User, however my peers recently advised
that all our
logging should be written like:
if(logger.isDebugEnabled()) {
logger.debug("Entry number: " + i + " is " +
String.valueOf(entry[i])); }
Personally, I think that is an absolute abomination, and a major failure
of the logging framework / Java combination.
That amount of extraneous 'noise', required typing (probably), and usage
of screen real-estate in the source code will clearly discourage regular
usage of detailed logging output.
When most methods should be a handful of lines, and most methods should
be
able to log at the most detailed log level, that amount of overhead is
really annoying.
Completely unacceptable in my books.
It should be simple, succent and efficient.
For gods sake, this was all figured out in the 70's with the C
pre-processor.
OK, not really Log4J's problem - More a Java limitation...
And yes, I have been pointed to Aspect compiler solutions (Almost
passable).
I'm just dissappointed that the solution here is not very elegant, given
the maturity of Java.
Sigh, history so often repeats itself...
-----Original Message-----
From: Lilianne E. Blaze [mailto:lilianne_blaze@tlen.pl]
Sent: Wednesday, 11 June 2008 2:05 PM
To: Log4J Users List
Subject: Re: log4j best practises
Hello,
Quite an useful text.
One thing I can't agree with:
"I recommend skipping the generalization if possible. You will have more
control over log4j if you use it directly. You cannot execute log4j's
PropertyConfigurator.configure( "/etc/log4j.properties" ) at your
leisure if using "commons-logging"."
You can use JCL everywhere except the config part where you use Log4j
directly. If you're forced to change logging api you only have to change
one or two files instead of the whole project.
Speaking of best practices - is it really better to use things like
logger.debug("The entry is {}.", entry);
instead of
if(logger.isDebugEnabled()) {
logger.debug("Entry number: " + i + " is " +
String.valueOf(entry[i])); }
Sure the first one is shorter, but isn't the second one faster?
Greetings, Lilianne E. Balze
Julius Davies wrote:
> Here's a page of what I consider log4j best practises:
>
> http://juliusdavies.ca/logging.html
>
>
> Any comments are very welcome!
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: log4j best practises - logger.isDebugEnabled()
Posted by Peter Nann <pe...@vecommerce.com.au>.
Thanks for the tip.
I suppose it still makes a method call and few references pushed onto
the stack, yes?
A major saving over the alternative I suppose...
(And regards history) - Now we are going back to printf() style
conventions.
How amusing.
-----Original Message-----
From: Curt Arnold [mailto:carnold@apache.org]
Sent: Wednesday, 11 June 2008 3:16 PM
To: Log4J Users List
Subject: Re: log4j best practises - logger.isDebugEnabled()
On Jun 10, 2008, at 11:42 PM, Peter Nann wrote:
>
> I am only a peripheral Log4J User, however my peers recently advised
> that all our logging should be written like:
>
> if(logger.isDebugEnabled()) {
> logger.debug("Entry number: " + i + " is " +
> String.valueOf(entry[i])); }
>
> Personally, I think that is an absolute abomination, and a major
> failure of the logging framework / Java combination.
>
> That amount of extraneous 'noise', required typing (probably), and
> usage of screen real-estate in the source code will clearly discourage
> regular usage of detailed logging output.
>
> When most methods should be a handful of lines, and most methods
> should be able to log at the most detailed log level, that amount of
> overhead is really annoying.
>
> Completely unacceptable in my books.
>
> It should be simple, succent and efficient.
>
> For gods sake, this was all figured out in the 70's with the C
> pre-processor.
> OK, not really Log4J's problem - More a Java limitation...
> And yes, I have been pointed to Aspect compiler solutions (Almost
> passable).
>
>
> I'm just dissappointed that the solution here is not very elegant,
> given the maturity of Java.
>
>
> Sigh, history so often repeats itself...
>
>
I would recommend using LogMF in the extras companion (or use LogSF if
you have to maintain code that uses log4j 1.3/SLF4J format strings
instead of java.text.MessageFormat message strings).
LogMF.debug(logger, "Entry number: {0} is {1}", i, entry[i]);
LogMF goes to a lot of effort to make that efficient and the you'd be
hard pressed to beat it with custom code. It shortcircuits if the
threshold is not met and avoids the unconditional array creation that a
varargs approach would entail.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: log4j best practises - logger.isDebugEnabled()
Posted by Curt Arnold <ca...@apache.org>.
On Jun 10, 2008, at 11:42 PM, Peter Nann wrote:
>
> I am only a peripheral Log4J User, however my peers recently advised
> that all our
> logging should be written like:
>
> if(logger.isDebugEnabled()) {
> logger.debug("Entry number: " + i + " is " +
> String.valueOf(entry[i])); }
>
> Personally, I think that is an absolute abomination, and a major
> failure
> of the logging framework / Java combination.
>
> That amount of extraneous 'noise', required typing (probably), and
> usage
> of screen real-estate in the source code will clearly discourage
> regular
> usage of detailed logging output.
>
> When most methods should be a handful of lines, and most methods
> should
> be
> able to log at the most detailed log level, that amount of overhead is
> really annoying.
>
> Completely unacceptable in my books.
>
> It should be simple, succent and efficient.
>
> For gods sake, this was all figured out in the 70's with the C
> pre-processor.
> OK, not really Log4J's problem - More a Java limitation...
> And yes, I have been pointed to Aspect compiler solutions (Almost
> passable).
>
>
> I'm just dissappointed that the solution here is not very elegant,
> given
> the maturity of Java.
>
>
> Sigh, history so often repeats itself...
>
>
I would recommend using LogMF in the extras companion (or use LogSF if
you have to maintain code that uses log4j 1.3/SLF4J format strings
instead of java.text.MessageFormat message strings).
LogMF.debug(logger, "Entry number: {0} is {1}", i, entry[i]);
LogMF goes to a lot of effort to make that efficient and the you'd be
hard pressed to beat it with custom code. It shortcircuits if the
threshold is not met and avoids the unconditional array creation that
a varargs approach would entail.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: log4j best practises - logger.isDebugEnabled()
Posted by Jason Irwin <ja...@mail.com>.
>if(logger.isDebugEnabled()) {
> logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i])); }
>Personally, I think that is an absolute abomination, and a major failure
>of the logging framework / Java combination.
It certainly makes the code ugly. If I am going to use an "isDebugEnabled"
check, I try to put as much logging in there as possible. If the check
begins to appear three or four times in a method, I usually begin to wonder
if the method is over-complex or if I am logging entirely the wrong stuff.
If I am just logging a string plain message (e.g. "Connection closed" or
whatever) I just log it, I feel the "isDebugEnabled" check is an overhead in
this simple case.
If there is any processing or method calls in the log message, then that
should be in a guard for performance.
> And yes, I have been pointed to Aspect compiler solutions (Almost
passable).
I have also wondered if it would (somehow) be possible to use Aspects to
"load in" different logging strategies, thus keep the method clean and doing
what it is supposed to do. Although I have not yet had time to investigate
Aspects beyond reading the "Idiot's Guide".
I wrote a very crude FindBugs detector (and I do mean CRUDE!) to look for
classes with no logging, and complex logging (as in your example) without
the appropriate "Enabled" guard. I should really go back and clean that up
at some point. It certainly was an eye-opener when I pointed at a few
people's code... :o)
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org