Yes Ceki, adding "org.slf4j.ext.LoggerWrapper" to framework packages as per your recipe solved the problem for me, thank you. And what is your opinion: may "org.slf4j.ext.LoggerWrapper" or "org.slf4j.ext" deserve being checked by ClassOfCallerConverter.isInFrameworkSpace() similarly to "org.slf4j.Logger"? My best regards, Sergey On 08.03.15 12:29, Ceki Gülcü wrote:
Hi Sergey,
The list of framework boundaries can be adjusted by invoking
context.getFrameworkPackages().add("package of your choice");
where context can be obtained by
LoggerContext context = (LoggerContext) org.slf4j.LoggerFactory.getILoggerFactory();
Let us know if this works for you.
-- Ceki
On 3/7/2015 13:05, USHAKOV, Sergey wrote:
Hi,
I have currently come across an issue that if a org.slf4j.ext.LoggerWrapper subclass is used as logger in combination with Logback, then any logging methods inherited from it are prevented from location information being logged: class, method and line number are all replaced with question marks. Only methods overridden by a subclass are logged correctly.
The reason seems to be that ch.qos.logback.classic.spi.ClassOfCallerConverter#isInFrameworkSpace() method only recognizes "org.slf4j.Logger" and "org.apache.log4j.Category" as appropriate stack trace delimiters, and "org.slf4j.ext.LoggerWrapper" fails to be recognized.
My guess is that "org.slf4j.ext.LoggerWrapper" should be allowed to serve as stack trace delimiter somehow, be it explicitly by class name or implicitly by package name, or any other way...
Does it look like a minor bug in Logback with respect to LoggerWrapper?
Or if I am mistaken, please advise of any other appropriate way to get location information from org.slf4j.ext.LoggerWrapper ...
Thanks and best regards, Sergey _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user