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

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to