Hi Ceki, Thanks for the pointer, that helped me solve the problem. Can you explain a bit more about "FQCN" in LocationAwareLogger ? Does it just exclude particular stack frames (for class/methods in message patterns, and exception stack traces), first occurrence, all occurrences, or "look down the stack and hide everything until found"? Thanks, Christopher On Tuesday, 7 June 2011, Ceki Gülcü <ceki@qos.ch> wrote:

Hi Christopher,

Have a look at slf4j's XLogger [1] class. Note that it subclasses LoggerWrapper [2] which is responsible for most of the delegation work and preservation of caller origin.

Shout if things remain unclear,

-- Ceki

[1] http://slf4j.org/xref/org/slf4j/ext/XLogger.html [2] http://slf4j.org/xref/org/slf4j/ext/LoggerWrapper.html

On 07/06/2011 10:02 PM, Christopher BROWN wrote:

Hello,

I'm using Logback classic via the SLF4J API, in a big application where other log APIs (some standard, such as OSGI logging, and other proprietary in-house historical APIs) are present.

I would like to re-implement these APIs to "redirect" onto Logback classic, but to get to the point: it's a big API and I'm lost.  If I reimplement said APIs with a naive implementation that just calls into SLF4J or logback using the "user" API, I'll incur an extra stack frame in stack traces and generally hide the origin of calls.

What's the best, cleanest way of doing this (given SLF4J and the choice of logback classic) ?  I will add the Log4J API implementation to address some cases (the SLF4J implementation of Log4J APIs) but for the other stuff, I'm a bit stuck.

Thanks, Christopher

_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user