LogKit and Excalibur Logger

[Shash Chatterjee <sh...@hotmail.com>]

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

Re: LogKit and Excalibur Logger

[Shash Chatterjee <sh...@hotmail.com>]

I  tried this, since the changes are small enough, and it works.  Here are
the patches for review.

Shash

----- Original Message -----
From: "Shash Chatterjee" <sh...@hotmail.com>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Saturday, February 01, 2003 8:49 AM
Subject: LogKit and Excalibur Logger


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