I use your pattern in my code. There might be an issue for classes that can be serialized...I think I remember someone mentioning that some time back. But if the class will not be serialized, it is not an issue.
-Mark > -----Original Message----- > From: Jacob Kjome [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 18, 2002 2:18 PM > To: Log4J Users List > Subject: Re: log4j programming question... > > > Can someone please comment on my question below? > > thanks, > > Jake > > 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 = > 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:[EMAIL PROTECTED] > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
