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ü <[email protected]> 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 > [email protected] > http://qos.ch/mailman/listinfo/logback-user > _______________________________________________ Logback-user mailing list [email protected] http://qos.ch/mailman/listinfo/logback-user
