[ https://jira.qos.ch/browse/SLF4J-436?page=com.atlassian.jira.plugin.system.i... ] Tobias Gruetzmacher commented on SLF4J-436: ------------------------------------------- Here is the (truncated) content of *trace* in *Util.getCallingClass()*: {noformat} org.slf4j.helpers.Util$ClassContextSecurityManager org.slf4j.helpers.Util org.slf4j.LoggerFactory x x org.slf4j.LoggerFactory$getLogger org.codehaus.groovy.runtime.callsite.CallSiteArray org.codehaus.groovy.runtime.callsite.AbstractCallSite org.codehaus.groovy.runtime.callsite.AbstractCallSite org.example.MismatchTest sun.reflect.NativeConstructorAccessorImpl sun.reflect.DelegatingConstructorAccessorImpl java.lang.reflect.Constructor org.junit.runners.BlockJUnit4ClassRunner{noformat} First column marks the entry which is selected by *getCallingClass()*, second column is the flag *isSynthetic* of that *Class<?>* object, this might be used to implement a workaround in *getCallingClass()* ... Would it be a viable solution to skip synthetic classes in this method? I wonder if it would be a good idea to also skip all those groovy frames somehow?!?
Logger name mismatch when using Spock -------------------------------------
Key: SLF4J-436 URL: https://jira.qos.ch/browse/SLF4J-436 Project: SLF4J Issue Type: Bug Components: Core API Affects Versions: 1.7.25, 1.8.0-beta2 Reporter: Tobias Gruetzmacher Assignee: SLF4J developers list Priority: Minor
When using the Spock Framework ([http://spockframework.org/)] in combination with *slf4j.detectLoggerNameMismatch* you get logger mismatch messages like this: {noformat} SLF4J: Detected logger name mismatch. Given name: "org.example.MismatchTest"; computed name: "org.slf4j.LoggerFactory$getLogger". SLF4J: See http://www.slf4j.org/codes.html#loggerNameMismatch for an explanation{noformat} It seems that Spock does some magic with its test classes... Sample maven project attached.
-- This message was sent by Atlassian JIRA (v7.3.1#73012)