Issue
I'm running Tomcat as an embedded server inside of a Springboot app, so all the additional functionality in JULI such as multiple class loaders etc is not needed and just gets in the way.
I just want my app to use java.util.logging
directly without the extra complication of JULI. I want a flat configuration where everything just flows directly to java.util.logging
and the way I have configured it.
How can I ditch JULI?
UPDATE
The actual problem I'm having is that I'm unable to load a custom Handler
... getting a ClassNotFound
. I initially thought this was caused by JULI but really seems to be related to Spring Boot's System Class Manager unwillingness to load classes from BOOT-INF
.
Solution
JULI is just a logging facade used by Tomcat for its internal logging (cf. javadoc) based on Apache Commons Logging. It is not a logging framework and does not perform any logging by itself.
By default it uses java.util.logging
plain and simple the way you configured it.
The additional functionality you can find in a standalone Tomcat (per classloader configuration, multiple handlers of the same class, etc.) is provided by ClassLoaderLogManager
. In order to use it you need to set:
-Djava.util.logging.logmanager=org.apache.juli.ClassLoaderLogManager
as JVM parameter (anywhere else it will be probably ignored).
Tomcat's startup scripts add the above mentioned Java system property, but your Spring Boot application almost certainly does not. Hence your application is using java.util.logging
plain and simple (unless you are using spring-boot-starter-logging
in which case java.util.logging
is redirected to LogBack).
TL;DR: by default Tomcat JULI simply forwards messages to java.util.logging
. There are no complications.
Answered By - Piotr P. Karwasz
Answer Checked By - Cary Denson (JavaFixing Admin)