Thanks, but that still has no effect. Still no log entry produced anywhere that I can find when it calls “getLogger().error(…” in StandardContext.
From: Christopher Schultz <[email protected]> Sent: Monday, November 10, 2025 6:46 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 3: 02 PM, KARR, DAVID wrote: > (Sorry about top-posting, my options are limited behind the firewall. ) Odd that the firewall affects this, but it's okay. :) > org. apache. juli. logging. LogFactory is in tomcat-embed-core, David, On 11/7/25 3:02 PM, KARR, DAVID wrote: > (Sorry about top-posting, my options are limited behind the firewall.) Odd that the firewall affects this, but it's okay. :) > 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 I believe these need to be in logging.properties. I don't think they will have any effect in application.properties or as system properties. -chris > From: Christopher Schultz > <[email protected]<mailto:[email protected]>> > Sent: Friday, November 7, 2025 11:13 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/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]<mailto:[email protected]%3cmailto:[email protected]>>> > >> Sent: Friday, November 7, 2025 8:40 AM > >> To: >> [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[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<mailto:ch.qos.logback.classic.jul.LevelChangePropagator@4eba373c%3cmailto:ch.qos.logback.classic.jul.LevelChangePropagator@4eba373c%3cmailto: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]<mailto:[email protected]%3cmailto:[email protected]%3cmailto:[email protected]%3cmailto:[email protected]>>> > >> > >> For additional commands, e-mail: >> [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]%3cmailto:[email protected]%3cmailto:[email protected]>>> > >> > >> > > > > > > --------------------------------------------------------------------- > > 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]>
