Details
-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
1.0.0
-
None
-
None
Description
This is probably best demonstrated with a code example;
package com.example;
import ch.qos.logback.classic.Level;
import ch.qos.logback.classic.Logger;
import ch.qos.logback.classic.LoggerContext;
import ch.qos.logback.classic.spi.LoggingEvent;
public class Test {
Logger logger;
public static void main(String[] args)
{ Test test = new Test(); test.go(); }private void go()
{ SuperClass anotherClass = new SuperClass(); anotherClass.go(); anotherClass = new SubClass(); anotherClass.go(); } private class SuperClass {
public void go() {
LoggerContext lc = new LoggerContext();
lc.setName("default");
// ... a logger
logger = lc.getLogger("root");
LoggingEvent le = new LoggingEvent(this.getClass().getName(),
logger, Level.DEBUG, "Test logging event", new Exception(
"test Ex"), new String[]
);
StackTraceElement[] callerData = le.getCallerData();
System.out.println("LoggingEvent in " + this.getClass().getName() + " has "
+ callerData.length + " stack trace elements:");
for (StackTraceElement stackTraceElement : callerData)
}
}
private class SubClass extends SuperClass {
}
}
The output of this is as follows;
LoggingEvent in com.example.Test$SuperClass has 2 stack trace elements:
Element=com.example.Test.go(Test.java:20)
Element=com.example.Test.main(Test.java:14)
LoggingEvent in com.example.Test$SubClass has 0 stack trace elements:
This is despite exactly the same go() method being called; it's not being modified in the subclass. Note that although the example uses inner classes, the same behaviour is exhibited in regular classes too.