[ https://issues.apache.org/jira/browse/LOG4J2-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17334719#comment-17334719 ]
Carter Kozak commented on LOG4J2-3083: -------------------------------------- I recently modified this code, but I tried not to modify the algorithm much, so I likely didn't make the issue any better. In hindsight I should have thought to add a status-logger trace level line to print the anchor class for easier debugging. > StackLocatorUtil.getCallerClass() walks the stack until it finds the FQCN. It > then skips any stack entries that match the FQCN. It then stops when it has a > stack element that matches the package. That seems wrong. It should be > looking for the first class that doesn't match the package to find the > caller. I will need to create a unit test to verify this is a bug. My understanding was that we wanted to find Log4jLoggerFactory, walk up (through the AbstractLoggerFactory call) until we found slf4j code, which we expect to be org.slf4j.LoggerFactory.getLogger(String). In this case, calls come from non-slf4j sources which means we traverse the entire stack (fairly expensive), come up with no anchor class, and use the default context. I think you're right that we want to use a set of opt-out package prefixes rather than opt-in, so that we can walk the tree to find the first class that's neither from org.apache.logging.log4j nor org.slf4j. I can take this issue given my recent work in this area of the codebase. > Why the logger get by Slf4j LoggerFactory.getILoggerFactory() can only use > current LoggerContext > ------------------------------------------------------------------------------------------------ > > Key: LOG4J2-3083 > URL: https://issues.apache.org/jira/browse/LOG4J2-3083 > Project: Log4j 2 > Issue Type: Question > Affects Versions: 2.13.3 > Environment: Spring Boot 2.4.5 > Slf4j > Reporter: wanghao > Assignee: Ralph Goers > Priority: Major > Labels: newbie > > In SpringBoot project with +test+ profile, > org.slf4j.LoggerFactory.getLogger("xxx") can get test profile LoggerContext > and read configuration from log4j2-test.xml. > But > org.slf4j.LoggerFactory.getILoggerFactory().getLogger("xxx") can only get > current LoggerContext and read configuration from log4j2.xml. > > Is it designed like this? Why? -- This message was sent by Atlassian Jira (v8.3.4#803005)