Skip to content

Commit 70f5c9f

Browse files
committed
Always use String getLogger with log4j
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.
1 parent 1b6a080 commit 70f5c9f

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)