(Sorry about top-posting, my options are limited behind the firewall.) org.apache.juli.logging.LogFactory is in tomcat-embed-core, used by both the “good” service and the “bad” service.
I tried adding the following to both application.properties and with “-D” options on the command line: logging.level.org.apache.catalina=DEBUG logging.level.org.apache.catalina.core.StandardContext=DEBUG logging.level.org.apache.catalina.core.ContainerBase=DEBUG No difference. From: Christopher Schultz <[email protected]> Sent: Friday, November 7, 2025 11:13 AM To: [email protected] Subject: Re: Still struggling with getting root causes of exceptions in tomcat-embed-core in SpringBoot applications David, On 11/7/25 1: 04 PM, KARR, DAVID wrote: > In the dependency tree of one of the services that is still not showing the log entry, I see logback-core, logback-classic, and log4j-to-slf4j. In one service that is showing the log entry, ZjQcmQRYFpfptBannerEnd David, On 11/7/25 1:04 PM, KARR, DAVID wrote: > In the dependency tree of one of the services that is still not showing the > log entry, I see logback-core, logback-classic, and log4j-to-slf4j. In one > service that is showing the log entry, it only has logback-classic. The > service that is not showing the log entry is using a NEWER version of > springboot than the one that is showing it, along with a newer patch version > of logback. > > I also see that “org.apache.juli.logging.Log”, a class in tomcat-juli, is > also present in tomcat-embed-core. Both the “good” and “bad” service use the > same version of tomcat-embed-core. > > I remember now that we actually already have a “logging.properties” file in > the classpath of both services, with the following contents: > handlers = java.util.logging.ConsoleHandler > java.util.logging.ConsoleHandler.level = ALL > java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter Can you find a JAR file which contains this class: org.apache.juli.logging.LogFactory ? I do see that StandardContext seems to have a big of split-personality when it comes to logging. Sometimes, it logs to this logger: org.apache.catalina.core.StandardContext.log And sometimes it logs to this one: org.apache.catalina.core.ContainerBase.log If you have specific configuration to enable DEBUG or TRACE logging for StandardContext, consider enabling it for both StandardContext and also ContainerBase. -chris > From: Christopher Schultz > <[email protected]<mailto:[email protected]>> > Sent: Friday, November 7, 2025 8:40 AM > To: [email protected]<mailto:[email protected]> > Subject: Re: Still struggling with getting root causes of exceptions in > tomcat-embed-core in SpringBoot applications > > David, On 11/6/25 1: 51 PM, KARR, DAVID wrote: > We support a large number of > SpringBoot applications using tomcat-embed-core (currently at 10. 1. 41). > There are some configuration issues that result in the service startup > failing with a "Tomcat > ZjQcmQRYFpfptBannerEnd > > David, > > > > On 11/6/25 1:51 PM, KARR, DAVID wrote: > >> We support a large number of SpringBoot applications using tomcat-embed-core >> (currently at 10.1.41). There are some configuration issues that result in >> the service startup failing with a "Tomcat startup" exception, which >> provides no information about the actual root cause. > >> > >> I've spent a lot of time looking at the Tomcat "StandardContext" class for >> this. The catch clauses in that typically call "getLogger().error(...". I >> find that I can set breakpoints at all the "ok = false" lines, and if the >> root cause is repeatable on my desktop (pretty rare, actually), I can set a >> breakpoint there and inspect the exception in the catch clause, but the log >> statement doesn't appear anywhere that I can find. > >> > >> I've asked related questions about this in the past, and there were times >> that I thought I had a solution, but I now know I do not. It appears that >> since the "bridge" artifact is in use, we can set "logging.level." >> properties. However, I have a feeling that only affects the log statements >> that directly use the "log" instance variable defined directly in >> "StandardContext". It doesn't seem to have any effect on the catch clauses >> that use "getLogger().error(...". > >> > >> I now have a simple and repeatable test case for this, so I can experiment >> with variations, but I'm still unable to get this to show the actual root >> cause. > >> > >> I also note that although our services are mostly on v10.1.41 of >> tomcat-embed-core, I see different behavior depending on what version of >> SpringBoot they are using. In one service that is not showing the root >> cause, I find that it is using version 3.3.11 of SpringBoot, which also >> results in version 1.5.18 of logback-core. Another service is using a >> slightly older version of SpringBoot, version 3.3.4 (logback-core 1.5.8), >> and that one IS showing the root cause. > >> > >> Over the last few months when I've struggled with this, I've tried other >> variations like a "logging.properties" file that sets Catalina-specific >> properties, but I don't think that made any difference, although that was >> before I had this repeatable test case. > >> > >> I also note that in the service that shows the root cause, I see this in my >> log: > >> > >> 08:43:14,376 |-INFO in >> ch.qos.logback.classic.jul.LevelChangePropagator@4eba373c<mailto:ch.qos.logback.classic.jul.LevelChangePropagator@4eba373c<mailto:ch.qos.logback.classic.jul.LevelChangePropagator@4eba373c%3cmailto:ch.qos.logback.classic.jul.LevelChangePropagator@4eba373c>> >> - Propagating DEBUG level on Logger[org.apache.catalina] onto the JUL >> framework > >> > >> I do NOT see that in the service that is not showing the root cause. > > > > What other logging-related libraries are being deployed along with your > > application. You mentioned logback. Is there anything else? For example, > > tomcat-juli.jar? > > > > If tomcat-juli.jar is present, then logging.properties will be used by > > java.util.logging to produce logs. > > > > If, however, you (or Spring) have installed some other kind of logging > > bridge over to logback, then logging.properties will probably be ignored > > in favor of however logback is configured. > > > > -chris > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>> > > For additional commands, e-mail: > [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected]<mailto:[email protected]> For additional commands, e-mail: [email protected]<mailto:[email protected]>
