[I've tried, and LogKit does return the same Logger for each call with the same category.]
As it happens, I've just finished working on some code that should avoid the need to make different edits to each class file. Not my idea - a colleague at work sent me details (derived from a Usenet posting) which used the protected method getClassContext() in SecurityManager. This became ClassContext. [The changes to LoggingManager are mine.] See http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20532 - ClassContext and http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20533 - LoggingManager updates This should work in Java 1.3+ - at least in JMeter which does not install it's own Security Manager. The logger call now becomes LoggingManager.getLoggerForClass() or LoggingManager.getLoggerForClass("ignored") [with appropriate import changes if necessary] The second method makes it easier to edit the source, as the original string (which may be on the next line) does not have to be removed. Anyway, perhaps the string should be kept, in case it later proves useful as part of the category name ? For flexibility, I deliberately left the original getLoggerFor() method unchanged, but it could be converted to behave as per the new methods. Rather than use the full class name, the code removes the "org,apache." prefix. This is closer to the original scheme. Some other minor changes mean that no jmeter log properties are needed; the defaults are: log_file=jmeter.log log_level=INFO but the usual properties still work, with the addition of individual log files for category hierarchies: log_file.jmeter.engine=engine.log log_level.jmeter.engine=DEBUG If this seems reasonable, the patches are in the bug reports. Give it a whirl! The new code should work without changing existing logging calls. (I've not been able to test it on Java 1.3 yet) I'm sure there are some improvements that can be made, but hopefully it's a reasonable start. == BTW, Jedit has a global search/replace which can handle multi-line edits. >From memory: Match: getLoggerFor\((.|\n)*?\) Replace: getLoggerForClass() I also found the Class Hierarchy Eclipse plug-in from SourceForge very useful: http://eclipse-tools.sourceforge.net/ HTH Sebastian P.S. Thanks to Mike for his help and patience in discussing some of the finer points of logging. And for its simple design, which made it easy to do... -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 05 June 2003 21:43 To: JMeter Developers List Subject: Re: Logging suggestions That's a fair reason to keep it static. It's unfortunate though because that means each instance needs to be changed by hand. -Mike On 5 Jun 2003 at 21:09, Jeremy Arnold wrote: > Hello, > 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] > -- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 AIM: mstover777 --------------------------------------------------------------------- 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]
