[jboss-jira] [JBoss JIRA] (LOGMGR-260) System loggers run with level ALL
[
https://issues.jboss.org/browse/LOGMGR-260?page=com.atlassian.jira.plugin...
]
James Perkins commented on LOGMGR-260:
--------------------------------------
Yes sorry. That's part of [JEP 264|https://openjdk.java.net/jeps/264] which defines a
platform logger. The default implementation of the {{System.Logger}} uses a
{{java.util.logging.Logger}}. In LOGMGR-213 we introduced our own {{System.LoggerFinder}}.
This would also get around the issue because the backing logger used in the
{{System.Logger}} would be a {{org.jboss.logmanager.Logger}} so the issue wouldn't be
seen.
That said the service loader can't find the {{System.LoggerFinder}} in the log manager
because the log manager isn't on the system class path. Really not the issue reported
here, but something I noticed and wanted to make note of is all :) I'll likely have to
file a MODULES issue for this though.
System loggers run with level ALL
---------------------------------
Key: LOGMGR-260
URL: https://issues.jboss.org/browse/LOGMGR-260
Project: JBoss Log Manager
Issue Type: Bug
Components: core
Environment: Java 9+
Reporter: Philippe Marschall
Priority: Major
After migrating to Java 11 we were suddenly seeing a lot of caught exceptions
{{sun.rmi.runtime.Log#getSource()}}. This was surprising to use because we WildFly which
sets the "sun.rmi" logger to level WARN. Upon closer inspection the issue is
that the logger used by {{sun.rmi.runtime.Log}} has level ALL ({{Integer#MIN_VALUE}}).
The issue for this seems to be the following:
# since Java 9 java.util.logging differentiates between system loggers (used by modules
in the platform classloader) and user loggers (everything else), see
{{java.util.logging#Logger.demandLogger(String, String, Class<?>)}}
# when a system logger is created a second user logger is created and their
configurations are merged, however they are merged based on internal state maintained by
{{#setLevel(Level)}}, see {{java.util.logging.LogManager#demandSystemLogger(String,
String, Module)}} and {{java.util.logging.Logger#mergeWithSystemLogger(Logger)}}
# {{org.jboss.logmanager.Logger}} only ends up calling {{#setLevel(Level)}} with
{{Level.ALL}} therefore the resulting system logger always has the level ALL
The issue is quite hard to test because:
# the effect only happens when the caller of {{#getLoggger(String)}} is a system module
# the log output is not different, only {{#isLoggable(Level)}} checks that shouldn't
succeed suddenly succeed so you only see the overhead
--
This message was sent by Atlassian Jira
(v7.13.8#713008)