Hi, I always use private static final Logger LOGGER = Logger.getLogger(Foo.class);
I use static final instead of final static because the former is the JLS recommended order, and tools like Checkstyle complain if you don't comply, but the functionality is the same obviously. I use private because public is an anti-pattern, package-scope is almost as bad, and I don't want to use protected because I want to force classes/people who extend my own classes to provide their own Logger for better separation and identification. This scheme has worked well for me in production, on big and small apps, in and out of Servlet and J2EE contaienrs, for years now. Yoav Shapira Millennium Research Informatics >-----Original Message----- >From: McCarty, Brian [mailto:[EMAIL PROTECTED] >Sent: Friday, October 01, 2004 10:48 AM >To: Log4J Users List >Subject: RE: Making the logger private > >I normally declare them private, because they are specific to each of my >Classes. But what about 'final'? I have seen it done both ways in >examples so I am not sure what's best. > >Should I use: > private final static Logger.... >or > private static Logger... > >Thanks for helping with my understanding. > >Brian > >PS: I have a short lived "user" application and a long running app >server application both to think about. > >-----Original Message----- >From: Jim Moore [mailto:[EMAIL PROTECTED] >Sent: Friday, October 01, 2004 8:49 AM >To: Log4J Users List >Subject: Re: Making the logger private > >I'm not sure what exampled you're referring to showing the public >usage -- most everything I could find shows it being either private or >"package"... > >The two canonical ways of creating Loggers are: > private static final Logger LOG = Logger.getLogger(MyClass.class); >or > private final Logger logger = Logger.getLogger(getClass()); > >The static route is nice because (assuming you have many more >instances than you have classes) it's more efficient, and when it logs >you know exactly what class the logging is coming from so it's easy to >track down where it happened. However, if it's a class that likely >will be extended from, it doesn't tell you exactly what "kind" of >instance the calling object really is. The advantages/disadvantages >are reversed for the non-static logger. It depends on your needs, of >course, but in general the static Logger has the better cost/benefit >ratio. > >That said, making Logger public would actually be an anti-pattern. >"Sharing" a Logger between classes makes it extremely difficult and >misleading to determine where the logging is taking place. Logger >instances aren't zero-cost, but they aren't expensive either, so >unless you have extreme performance requirements, it's best to do what >makes debugging easier, which is either a Logger-per-class or a >Logger-per-instance. If you absolutely need a "public Logger", use >the root logger (Logger.getRootLogger()). > >There are some special-case exceptions, though, that basically >boil-down to trying to do AOP without actually doing AOP. An example >is having a SQL_LOGGER that's used across classes when doing SQL. >That's better handled using other techniques, however. > >-Jim Moore > > >On Fri, 1 Oct 2004 09:56:57 +0100, [EMAIL PROTECTED] ><[EMAIL PROTECTED]> wrote: >> >> Hi all >> >> just a little question. >> In all log4j examples I see the logger is integrated as >> >> public static Logger logger = new Logger(x.class); >> >> If I understand it correct, it is static to enhance the performance, >as >> only one instance of the logger is used for all instantiations of >class x. >> But why is it public? I would make it private as it is referenced only >in >> the class x, not outside. >> >> And if i don't want to extend the class x, I would make it final. >> >> Thus in my example it would be: >> private static final Logger logger = new Logger(x.class); >> >> Are there any arguments speaking against this usage? Please make >> suggestions. >> >> Thanks Herb > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
