We are already doing something similar to that (our categories are named
based on the class name and package); however, it still does not help us
out when dealing with determining the originating method. Right now,
we've hacked together some utility methods to log when a thread enters and
leaves a method, but this is largely a replication of code already present
in log4j.
-Mike Wolf
"Sam Newman" <[EMAIL PROTECTED]>
07/17/01 05:24 PM
Please respond to "LOG4J Users Mailing List"
To: "LOG4J Users Mailing List" <[EMAIL PROTECTED]>
cc:
Subject: Re: Designing Logging class
I simply pass in the class of the object/static calling the abstract
logger - e.g. LogFactory.getInstance().error(this.getClass(), "error!");
sam
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "LOG4J Users Mailing List" <[EMAIL PROTECTED]>
Sent: Tuesday, July 17, 2001 5:56 PM
Subject: RE: Designing Logging class
> For the project I'm working on, we've done something similar. The one
> problem
> that you run into when you do this (or use any sort of abstraction for
> logging) is that
> log4j will no longer be able to accurately determine runtime information
> such as
> the calling method/class/line number. The reason for this is that this
> information is
> determined by generating a Throwable and then locating the relevant
> information in
> the call stack. By using an abstraction layer, you throw off the
> calculation, so it ends up
> always saying that the calling method is your abstracted log method.
>
> If anyone has found a way to get around this, feel free to comment.
>
> -Mike
---------------------------------------------------------------------
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]
