Hi, Lilanne,
I'm not a log4j expert, but I'll try to reply.
On Tue, Jun 10, 2008 at 9:04 PM, Lilianne E. Blaze
<[EMAIL PROTECTED]> wrote:
> Hello,
> Quite an useful text.
>
Thanks!!!
> 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.
>
Good point. I like your hybrid approach of using Log4J directly, but
only in a few tiny spots, and otherwise using JCL or SLF4J.
> 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?
>
Assuming an optimal implementation of both in the underlying logging
framework, here's what I suspect (but don't really know):
If DEBUG is disabled they should be the same speed. (As long as Java5
varargs aren't used to implement #1.... those seem to cause a slight
slowdown). The 1st one will not bother replacing {} with "entry" if
debug is not enabled.
If DEBUG is enabled, #1 will probably be faster. I don't remember
exactly, but I think the string concat operator ("+") doesn't prep the
StringBuilder it actually uses with a good initial size, so it may
have to resize itself. However, if you used StringBuilder instead of
the + operator, #2 and #1 would become about the same speed (very very
very slight edge to #2). By now #2 is turning into a 25 line gob of
ugliness, so I still prefer #1.
I think #1 is the best approach, even with varargs. Of course if
you're using JCL or Log4J directly, you can't do #1! :-) Which
brings up another best practice: if you're going to use one of these
"generalization" frameworks, make sure you use the best one! Or else
you might have to switch your "log generalization framework"!
(By the way, the best LGF doesn't show up until the year 2888, so I'm
not sure what we should do until then!)
j/k
Thanks for your post!
yours,
Julius
>
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
yours,
Julius Davies
250-592-2284 (Home)
250-893-4579 (Mobile)
http://juliusdavies.ca/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
