Re[3]: log4j programming question...

[Jacob Kjome <ho...@visi.com>]

One update.  I got an email from another user who said to explicitly
cast to a Logger because "Logger.getInstance() returns a Category for backwards compatibility,
so you need to cast."

So, it would be:

transient final private static Logger logger = (Logger)Logger.getLogger{MyClass.class.getName());

or does that not affect getLogger(), but only getInstance()?

Jake

Thursday, July 18, 2002, 4:38:29 PM, you wrote:

JK> Hello Scott,

JK> Thanks.  Sounds like using transient also addresses Mark's comment
JK> about serialization.  So, would the consensus be the following?

JK> transient final private static Logger logger = Logger.getLogger{MyClass.class.getName());

JK> Jake

JK> Thursday, July 18, 2002, 4:23:30 PM, you wrote:

KST>> I usually add transient - just for good measure

KST>> -----Original Message-----
KST>> From: Jacob Kjome [mailto:hoju@visi.com]
KST>> Sent: Thursday, July 18, 2002 2:18 PM
KST>> To: Log4J Users List
KST>> Subject: Re: log4j programming question...


KST>> Can someone please comment on my question below?

KST>> thanks,

KST>> Jake

KST>> Wednesday, July 17, 2002, 3:26:19 PM, you wrote:

JK>>> Hi,

JK>>> I have seen some cases where loggers are defined as "public", some as
JK>>> "protected", some as "private", and some as the default package level
JK>>> visibility.  Along the same lines, I have seen cases where loggers are
JK>>> defined as "static" and others non-static.  I have also seen some
JK>>> cases where the logger is defined as "final".

JK>>> What would be the "best practice" here?  Would it depend on the
JK>>> application?  Is there an advantage for subclasses to have access to
JK>>> the parent class logger as those defined as "public" and "protected"
JK>>> would be visible to subclases?  Shouldn't subclasses be using their
JK>>> own loggers?

JK>>> I would think that the following would be the best practice:

JK>>> final private static Logger logger =
KST>> Logger.getLogger{MyClass.class.getName());


JK>>> Is this the case?  I'm really just trying to get some validation here.
JK>>> Are there any disadvantages to the above?

JK>>> Thanks,

JK>>> Jake

  










-- 
Best regards,
 Jacob                            mailto:hoju@visi.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re[3]: log4j programming question...

[Ceki Gülcü <ce...@qos.ch>]

At 16:42 18.07.2002 -0500, Jacob Kjome wrote:

>One update.  I got an email from another user who said to explicitly
>cast to a Logger because "Logger.getInstance() returns a Category for 
>backwards compatibility,
>so you need to cast."

The above sentence although formally correct can be misread. To avoid
confusion, let me insist that log4j 1.2 ALWAYS produces Logger
instances. It is actually quite impossible to force log4j to produce
Category instances which are not of type Logger.

The signatures of the Logger.getInstance() or Category.getInstance()
methods specify that they return a Category object. But in reality
they actually return a Logger object. (Logger extends Category
implying that a Logger *is* a Category. The cast to Logger you mention
would not work otherwise.)

>So, it would be:
>
>transient final private static Logger logger = 
>(Logger)Logger.getLogger{MyClass.class.getName());
>
>or does that not affect getLogger(), but only getInstance()?
>
>Jake

--
Ceki


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>