Re: A default getLogger method

2009-01-28 Thread Brett Randall
Hi Brian, From the javadoc for Thread getStackTrace(): Some virtual machines may, under some circumstances, omit one or more stack frames from the stack trace. In the extreme case, a virtual machine that has no stack trace information concerning this thread is permitted to return a zero-length

Re: A default getLogger method

2009-01-28 Thread Craig P. Motlin
Maybe it will make your code less portable but I still think it's a good idea. It prevents you from initializing the Logger with this.getClass().getName(). The logger name shouldn't be the same as the run time type of the containing object anyway. My factory method may be even more brittle

Re: A default getLogger method

2009-01-28 Thread Douglas E Wegscheid
a good point, but the Brian (the original poster) was looking for a way to avoid having to provide the Class object when calling Logger.getLogger(Class clazz). He was suggesting a way to provide a no-args Logger.getLogger(). Having a no-args Logger.getLogger() would be really nice, but using

Re: A default getLogger method

2009-01-28 Thread Craig P. Motlin
Great, so we're in agreement. I guess I'm just looking for a case where it doesn't work with inheritance. I've only seen it work the same way as creating the Logger by passing in the class literal. Your very first example had the behavior I would expect - all log statements appeared to be from

Re: A default getLogger method

2009-01-28 Thread Douglas E Wegscheid
it's not what I expect. If I see an error message that is marked as being logged by class T1, I would expect to find the corresponding logging statement in class T1 or a superclass, not a subclass but that's just a style thing... Douglas E Wegscheid Lead Technical Analyst, Whirlpool

Re: A default getLogger method

2009-01-27 Thread Douglas E Wegscheid
if you want parameterized messages, use slf4j ;) -- Thread.currentThread() isn't there until Java 5 (though new Throwable ().getStackTrace() works fine on 1.4.2). a more serious problem: it doesn't work if you call getLogger() from a method in a superclass, then instantiate a subclass of that

Re: A default getLogger method

2009-01-27 Thread Craig P. Motlin
This is a non-issue. If you need to log an object's type, call getClass().getName() and log it as a normal message. Stick to one private static logger in each class. The logger name will represent where the logging statement occurred, not the run time type of the logging object. On Tue, Jan

Re: A default getLogger method

2009-01-27 Thread Brian Hawkins
You missed what I'm trying to do. I'm defining a static logger such as this: public class MyClass { private static final Logger myLogger = Logger.getLogger(MyClass.class); } But what I would like to do is this public class MyClass { private static final Logger myLogger = Logger.getLogger(); }

A default getLogger method

2009-01-26 Thread Brian Hawkins
I've liked the log4j Logger except for two things. The first is that I have to pass my class name to the logger when I get it, for example: private static Logger myLogger = Logger.getLogger(MyClass.class); This is fine but it is prone to cut and paste errors. A better solution is to add the

Re: A default getLogger method

2009-01-26 Thread Curt Arnold
On Jan 26, 2009, at 4:27 PM, Brian Hawkins wrote: I've liked the log4j Logger except for two things. The first is that I have to pass my class name to the logger when I get it, for example: private static Logger myLogger = Logger.getLogger(MyClass.class); This is fine but it is prone to