The constructor `java.util.logging.LogManager$RootLogger` in OpenJDK 8 no longer sets the log level. This causes the following test to fail: Logger current = ...; while (current.getLevel() == null && current.getParent() != null) { current = current.getParent(); } assertNotNull(current.getLevel()); As far as I understand the `java.util.logging.Logger` contract forbids both `getLevel()` and `getParent()` to return a null value. Steps to reproduce: * create an application with a `logging.properties` file without a `.level` property.
Sounds like a bug in Java, not Tomcat. Do you have a stack trace from where Tomcat triggers this?
Hi Christopher, (In reply to Christopher Schultz from comment #1) > Sounds like a bug in Java, not Tomcat. > > Do you have a stack trace from where Tomcat triggers this? The `LogManager` in JDK8 initializes the level of the root logger in `LogManager#ensureLogManagerInitialized()`, so it is not a Java bug: https://github.com/openjdk/jdk8u/blob/3dca446d440e55cbb7dc3555392f4520ec9ff3bc/jdk/src/share/classes/java/util/logging/LogManager.java#L350 Tomcat's `ClassLoaderLogManager` creates additional "root" loggers (one per classloader) and: * if the classloader does not contain a `logging.properties` resource, its root logger becomes a child of its parent classloader root logger, * otherwise the root classloader remains without a parent and without a level. I have submitted a PR with a test case: https://github.com/apache/tomcat/pull/533 The lack of a `Level` object does not prevent JUL from working, since the (inaccessible) effective int level is computed correctly. However this causes problems in code that need to access the effective level like this one: https://issues.apache.org/jira/browse/LOG4J2-3564
Thanks for the bug report and the PR. This has been fixed in: - 10.1.x for 10.1.0-M18 onwards - 10.0.x for 10.0.24 onwards - 9.0.x for 9.0.66 onwards - 8.5.x for 8.5.83 onwards