logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig P. Motlin" <mot...@gmail.com>
Subject Re: A default getLogger method
Date Wed, 28 Jan 2009 13:24:06 GMT
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 since I hardcoded a constant to get the
logger name.


The magic constant did make me uncomfortable so I wrote a unit test.

public void testLoggerFactory() {
  Logger logger = LoggerFactory.getLogger();
  assertEquals(LogTest.class.getName(), logger.getName());

This thread inspired me to write a few more tests with inheritance
where I assert that the logger name is always that of the base class.

On Wed, Jan 28, 2009 at 6:59 AM, Brett Randall <javabrett@gmail.com> wrote:
> 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 array from this method.".
> Hard to see a workaround for that, if it can/does happen.
> Cheers
> Brett
> On Wed, Jan 28, 2009 at 3:43 PM, Brian Hawkins <brianhks1@gmail.com> wrote:
>> 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();
>> }
>> Notice the getLogger call has not parameter now.  Inside of
>> Logger.getLogger() it does the stack trace to find the class that it is
>> being declared in.
>> I'm working on a Struts2 application with a lot of actions.  The tendency
>> is
>> when creating a new action to find one similar and cut and past it to the
>> new one.  The parameter to the getLogger call is easily missed when
>> renaming
>> the class name.  But with my change the getLogger call automagically
>> figures
>> out the class in which it is declared.  This creates cleaner code that is
>> easier to maintain.
>> Brian
>> On Tue, Jan 27, 2009 at 7:53 PM, Craig P. Motlin <motlin@gmail.com> wrote:
>> > 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.
>> >
>> >

To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message