using Logger.getGlobal() with tomcat9 and org.apache.logging.log4j.jul.LogManager - log4j config is ignored

We have a tomcat9 with a legacy application using jul for logging running. To be able to steer the log format easier and have MDC and some other features we use org.apache.logging.log4j.jul.LogManager and a log4j config file like so:

-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager
-Dlog4j.configurationFile="\path\to\file\log4j2.xml

this works very well for all loggers which are fetched via
Logger log = Logger.getLogger(LoggingTest.class.getName());

but in the legacy code there is also the GlobalLogger as well as Anonymous Loggers used e.g. like this (simplified but reproduces the problem):

Logger.getGlobal().log(Level.INFO, "bar with global");
Logger.getAnonymousLogger().log(Level.INFO, "bar with anonymous");

these are not logging via log4j but directly with Java Util ignoring the LogManager completely. The logger returned in these cases is not an instance of org.apache.logging.log4j.jul.CoreLogger but java.util.logging.Logger, although it's manager is still org.apache.logging.log4j.jul.LogManager.

Is this a known limitation and/or is there a workaround for that?

Looking at the source code it looks like Logger.getAnonymoustLogger() does a new Logger() directly instead of going through the LogManager. This makes it impossible for Log4j's replacement LogManager to properly support this as Log4j is expecting its LogManager replacement to be creating Loggers.

The GlobalLogger appears to also be setup with a new Logger() call during initialization. However, in your code above you show that you are calling getLogger() against the Global Logger which is a bit interesting since getLogger() is a static method and should behave just like Logger.getLogger() which ends up calling the LogManager to get a Logger, so in this case I am not sure why you would not also be getting a Log4j CoreLogger.