I would prefer the loggers to remain static if possible -- even if Logkit returns the same logger instance for each call, using a non-static reference will result in an object reference (to the logger) in each instance of a JMeter object. In a 64-bit JVM, this would generally make each JMeter object 8 bytes larger. With inheritance this can get worse, since you could have a logger reference at each level of inheritence. (As an extreme example, I've seen code with a deep inheritance hierarchy where each object instance required something like 400 bytes, and about half of that was for log object references. Of course, the hierarchy probably shouldn't have been 20 levels deep to start with...)
Is there something wrong with just using MyClass.class.getName( ) as the name of the logger? Something like:
public class MyClass {
private static Logger log = LoggerManager.getLoggerFor(MyClass.class.getName( ));
...
}
(Or define a new getLoggerFor which accepts a Class object and just calls getName( ) on it -- then you can just pass in MyClass.class.) That can cause errors when copy-pasting to a new class, although editors like Eclipse will update it properly when you tell it to copy a class. I also generally set up an Eclipse template to automatically create the logger for me so I don't have to worry about it.
Jeremy
[EMAIL PROTECTED] wrote:
Oh, well I didn't know - never read much of the logkit docs. If that's true, then there's no need for the log variables to be static in the first place. Remove the static keyword and user this.getClass().getName().
-Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
