org.ops4j.pax.logging.OSGIPaxLoggingManager.getLogger() calls org.ops4j.pax.logging.internal.BundleHelper.getCallerBundle(Bundle) which analyzes the stack of classes returned from java.lang.SecurityManager.getClassContext() and returns the first bundle which is not pax-logging bundle.
What do you think about making this behaviour configurable? Maybe additional filters to skip other classes?
Real example is where some bundle defines camel-route. The bundle found during creation of org.apache.camel.component.log.LogComponent is always camel-core, not the bundle which defines the route.
I have an idea how to fix it - together with PAXLOGGING-252. I'm taking this issue from you
Log4j1 analyzes stack trace (from new Throwable()) bottom-up and takes first class that's not the class passed explicitly as FQCN.
pax-logging's BundleHelper traverses top-down the stacktrace from org.ops4j.pax.logging.internal.BundleHelper.SecurityManagerEx#getClassContext and finds first class that has associated bundle that's not pax-logging-api.
pax-logging's org.ops4j.pax.logging.service.internal.JdkHandler#getCallerBundle traverses top-down the stacktrace from org.ops4j.pax.logging.service.internal.JdkHandler.SecurityManagerEx#getClassContext and finds first class that doesn't have name starting with org.ops4j.pax.logging or java.util.logging.
IMO, the FCQN approach is the best one.
Fixed in recent big changes related to PAXLOGGING-252.
https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-it/src/test/java/org/ops4j/pax/logging/it/Log4J1LocationInfoIntegrationTest.java (and Log4J2LocationInfoIntegrationTest.java and LogbackLocationInfoIntegrationTest.java) shows that location is correct now through all >10 APIs.