Hi! Since new releases are being discussed, I thought I'd bring this up. There is a known issue with the "method" formatter in LogKit's ExtendedPatterFormatter. The method shown is always the "caller" of Logger.class, which when used with a facade such as Excalibur Logger is *not* the user method, but always LogKitLogger. A while back, Peter Donald suggested a workaround, which works great. The workaround is to modify Excalibur Logger's FormatterFactory to support a custom formatter type, and then to implement that custom formatter with a modified version of ExtendedPatterFormatter that passes in, for instance, LogKitLogger.class instead of Logkit.class when calling StackIntrospector.getCallerMethod(...).
The one issue with this approach is we (Keel) have to carry a modified Logkit class, make sure it is ahead in the classpath from the rest of Avalon, etc. etc. I'd like to propose a backwards-compatible fix. If this sounds like an acceptable idea, I'll go ahead and test/submit a patch. Here goes: LogKit changes: - Create an ExtendedPatternFormatter constructor that takes an offset to the stack depth. In other words, this would specify looking for a class that is "offset" levels away from Logger.class on the stack. - Create a StackIntrospector.getCallerClass(Class, offset) - Modify ExtendedPatternFormatter to get the caller-class of Logger.class with an offset. If new constructor mentioned above is not used, offset is 0 and behaves like it does now. - Then use that to pass to StackIntrospector.getCallerMethod(...). Excalibur Logger changes: - Modify the "extended" type handling in FormatterFactory to call the new constructor above, with offset +1. Let me know if this is acceptable or not, before I delve into it. Thanks, Shash
