RE: Still struggling with getting root causes of exceptions in tomcat-embed-core in SpringBoot applications

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]>