Howdy,
>Hmm... No reason why they shouldn't. I'm not sure?
Because you can change loggers as well, they don't HAVE to be final.
They can be, and that's up to the developer, since the performance gain
is so small.
>>What's the school of thought between the naming conventions for the
logger
>>v
you see any Log4j docs that don't agree with what is
enforced in the code, speak up. Better yet, provide a patch correct it.
Jake
- Original Message -
From: "Shapira, Yoav" <[EMAIL PROTECTED]>
To: "Log4J Users List" <[EMAIL PROTECTED]>
Sent: Fri
ions also.
- Original Message -
From: "Shapira, Yoav" <[EMAIL PROTECTED]>
To: "Log4J Users List" <[EMAIL PROTECTED]>
Sent: Friday, January 16, 2004 5:37 PM
Subject: RE: Absolute performance
Howdy,
>private static final Logger LOG = Logger.getLogger(MyCla
PROTECTED]
Sent: 16 January 2004 17:33
To: Log4J Users List
Subject: Re: Absolute performance
I always spot my mistakes that moment after hitting send - of course it
should be -
private static final Logger LOG = Logger.getLogger(MyClass.class);
private static final boolean DEBUG_ENABLED
There is no problem with using final with the logger as I see no reason
why you would want to obtain
another logger instance post class initialization.
However, using a final boolean for the DEBUG flag would prevent the class
from detecting any run time
changes to the classes's level during th
Howdy,
>private static final Logger LOG = Logger.getLogger(MyClass.class);
This is good and I do it as well as recommend it to others.
>private static final boolean DEBUG_ENABLED = LOG.isDebugEnabled();
This is not good because isDebugEnabled potentially changes with time
during a program's ex
I always spot my mistakes that moment after hitting send - of course it should be -
private static final Logger LOG = Logger.getLogger(MyClass.class);
private static final boolean DEBUG_ENABLED = LOG.isDebugEnabled();
>
> From: <[EMAIL PROTECTED]>
> Date: 2004/01/16 Fri PM 05:30:29 GMT
> To: [EM
