Module io.jstach.rainbowgum.jul

module io.jstach.rainbowgum.jul
Rainbow Gum JUL (java.util.logging) integration. This module installs a Handler on the JUL root logger so that any java.util.logging.Logger usage (including from libraries and frameworks that log via JUL directly, e.g. embedded Tomcat) is routed through Rainbow Gum.

This is a separate module (rather than being bundled directly into io.jstach.rainbowgum.jdk) specifically so that it can be opted out of by simply excluding this artifact, instead of relying on a properties-based disable flag. To disable installation of the handler while still depending on this module set the property: "logging.jul.disable" to true. Alternatively if in a custom modular environment using jlink and the module java.logging is not included the handler will not be installed. Furthermore the module java.logging is not required and thus jlink might not automatically include it as it is requires static.

This module alone will not trigger Rainbow Gum to initialize. This is by design, and a real limitation of java.util.logging itself, not something Rainbow Gum works around. SLF4J's own org.slf4j.spi.SLF4JServiceProvider#initialize() callback runs automatically the first time application code touches org.slf4j.LoggerFactory, and System.Logger's System.LoggerFinder is resolved the first time anything calls System.getLogger(...). Plain java.util.logging.Logger.getLogger(name) has no equivalent ServiceLoader-style indirection at all: it talks straight to the classic LogManager. JULConfigurator is a io.jstach.rainbowgum.spi.RainbowGumServiceProvider.Configurator, which only runs as part of Rainbow Gum's own bootstrap sequence (it has no hook that could cause that bootstrap in the first place). A pure JUL application (nothing touching SLF4J or System.Logger anywhere, including incidentally via the JDK's own internals) that depends on this module alone will see no change at all: the bridge Handler is never installed, because nothing ever builds a Rainbow Gum for JULConfigurator to run against.

Two ways to fix this:

  • Depend on io.jstach.rainbowgum.jdk instead (which pulls this module in transitively) to get this working automatically. See doc/overview.html's "java.lang.System.Logger and java.util.logging" section for the full explanation, and examples/helidon's own README.md for a real, empirically-verified before/after.
  • If neither an existing System.Logger/SLF4J call site nor io.jstach.rainbowgum.jdk is an option, call io.jstach.rainbowgum.RainbowGum#of() explicitly before any JUL logging happens.