Skip to content

Commit 7795011

Browse files
prdoylerjernst
andauthored
Always use String getLogger with log4j (#121250) (#121421)
This commit forces the delegate for ES logging to always use the String version of LogManager.getLogger instead of the one taking a Class. The reason is that if a classloader is not in the hierarchy of the app classloader, the ES logging configuration will not be found. By using the String variant, the app classloader is always used. Co-authored-by: Ryan Ernst <[email protected]>
1 parent ad62101 commit 7795011

File tree

1 file changed

+7
-1
lines changed

1 file changed

+7
-1
lines changed

server/src/main/java/org/elasticsearch/common/logging/internal/LoggerFactoryImpl.java

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -22,6 +22,12 @@ public Logger getLogger(String name) {
2222

2323
@Override
2424
public Logger getLogger(Class<?> clazz) {
25-
return new LoggerImpl(LogManager.getLogger(clazz));
25+
// Elasticsearch configures logging at the root level, it does not support
26+
// programmatic configuration at the logger level. Log4j's method for
27+
// getting a logger by Class doesn't just use the class name, but also
28+
// scans the classloader hierarchy for programmatic configuration. Here we
29+
// just delegate to use the String class name so that regardless of which
30+
// classloader a class comes from, we will use the root logging config.
31+
return getLogger(clazz.getName());
2632
}
2733
}

0 commit comments

Comments
 (0)