[ http://jira.qos.ch/browse/LBCLASSIC-303?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-303: -------------------------------------- If the last argument is an exception it is treated as such. This change was introduced in SLF4J v 1.6.0. Here is the text: In the presence of multiple parameters and if the last argument in a logging statement is an exception, then SLF4J will now presume that the user wants the last argument to be treated as an exception and not a simple parameter. See the relevant FAQ entry for further details. This fixes bug 70 submitted by Joern Huxhorn who also provided the relevant patch. See also http://slf4j.org/faq.html#paramException Does the above help?
LoggingEvent.getCallerData() fails when called from a sub class ---------------------------------------------------------------
Key: LBCLASSIC-303 URL: http://jira.qos.ch/browse/LBCLASSIC-303 Project: logback-classic Issue Type: Bug Affects Versions: 1.0.0 Reporter: Greg Thomas Assignee: Logback dev list
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[] { "something" }); StackTraceElement[] callerData = le.getCallerData(); System.out.println("LoggingEvent in " + this.getClass().getName() + " has " + callerData.length + " stack trace elements:"); for (StackTraceElement stackTraceElement : callerData) { System.out.println("Element=" + stackTraceElement); } } } 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.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira