The last “Caused by” in that stack trace is the only “root cause” it is
providing. I had the developer running this build set the org.apache logger to
TRACE, and although I could verify that a couple of additional log messages
appeared, but nothing that provided any clue. The following is the previous
“o.a.c.l” logger entry before the startup failure, and this was quite a ways
before it:
{"@timestamp":"2025-05-14 19:50:25.323
GMT","level":"DEBUG","thread":"main","logger":"o.a.c.l.WebappClassLoaderBase","msgType":"SERVICE-MSG","sMsg":{"msg":"
--> Returning stream from parent"},"seq":34625,"format":"nf-v1.0"}
The service doesn’t fail when run on the desktop. The desktop configuration is
slightly different from the cluster configuration. I’ve compared every property
between the two and tried to copy some properties from the cluster config to
the desktop config, but that hasn’t shown any clues.
In other cases where the tomcat startup fails on the desktop, it’s typically an
obscure dependency conflict. I’ve been able to diagnose those by setting
breakpoints in the “StandardContext” class (every place where it sets “ok =
false”). The fact that it doesn’t fail on the desktop, but does fail in the
cluster, implies that it’s not an ordinary dependency conflict, but I don’t
know what it could be. In the StandardContext class, I see it writing log
messages with the exception info, but it appears that the changes I made to
“bridge” from jul to slf4j has no effect on those exception log statements, or
perhaps it’s simply not failing in any of those locations.
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Thursday, May 15, 2025 10:19 AM
To: users@tomcat.apache.org
Subject: Re: Still unable to get exception info from StandardContext in log
output
David, On 5/14/25 3: 50 PM, KARR, DAVID wrote: > I've tried several times to
configure tomcat-embed-core in SpringBoot to give me better log info when
Tomcat fails to start up. I thought I had this working, but apparently I was
mistaken. I
ZjQcmQR
YFpfptBannerEnd
David,
On 5/14/25 3:50 PM, KARR, DAVID wrote:
> I've tried several times to configure tomcat-embed-core in SpringBoot to give
> me better log info when Tomcat fails to start up. I thought I had this
> working, but apparently I was mistaken. I figured out how to get this
> information by stepping through the code in the debugger, when that is
> possible, but when the service is running in our Kubernetes clusters, that is
> not possible.
>
> I am presently using tomcat-embed-core 10.1.20.
>
> In the service's log file, I see this stacktrace (shortened a bit):
> ----------------
> org.springframework.context.ApplicationContextException: Unable to start web
> server
> at
> org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.onRefresh(ServletWebServerApplicationContext.java:165)
> at
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:618)
> at
> org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:146)
> Caused by: org.springframework.boot.web.server.WebServerException: Unable to
> start embedded Tomcat
> at
> org.springframework.boot.web.embedded.tomcat.TomcatWebServer.initialize(TomcatWebServer.java:145)
> at
> org.springframework.boot.web.embedded.tomcat.TomcatWebServer.<init>(TomcatWebServer.java:105)
> Caused by: java.lang.IllegalStateException:
> StandardEngine[Tomcat].StandardHost[localhost].TomcatEmbeddedContext[/msapi]
> failed to start
> at
> org.springframework.boot.web.embedded.tomcat.TomcatWebServer.rethrowDeferredStartupExceptions(TomcatWebServer.java:207)
> at
> org.springframework.boot.web.embedded.tomcat.TomcatWebServer.initialize(TomcatWebServer.java:129)
> -------------
>
> There is no other information in the previous log output that is useful.
>
> I had thought that the following steps would bridge the JUL logging to our
> slf4j/logback logger, but it is only partially effective.
>
> Add the following dependency information to the pom.xml:
> ====
> <dependency>
> <groupId>org.springframework.boot</groupId>
> <artifactId>spring-boot-starter-web</artifactId>
> <exclusions>
> <exclusion>
> <groupId>org.springframework.boot</groupId>
> <artifactId>spring-boot-starter-logging</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
> <dependency>
> <groupId>org.apache.logging.log4j</groupId>
> <artifactId>log4j-jul</artifactId>
> </dependency>
> ====
>
> Add the following to system.properties (not in main repo):
> =====
> java.util.logging.manager=org.apache.logging.log4j.jul.LogManager
> =====
>
> In your "logback.xml" (not in main repo), add this logger:
> ====
> <logger name="org.apache" level="ERROR" additivity="false">
> <appender-ref ref="STDOUT"/>
> </logger>
> ====
>
> With just these changes, I see no difference in the output at all. However,
> if I change the log level of the "org.apache" logger to TRACE, it does show
> some log entries from the logger whose name begins with "o.a.c." (it
> abbreviates the package name components to the first letter). That seems to
> indicate this is partially effective, but I still see no actual root cause
> info for the exception. It just says it failed to start up, and it doesn't
> say why.
>
> I have mentioned that if I can get it to fail in the same way on the desktop,
> I can step through the code in the debugger and inspect the actual exception
> that gets caught (a MultiException) and that shows the root cause. However,
> in the recent cases where I've been seeing this, the service doesn't fail
> when run on the desktop, only in our Kubernetes clusters, and I can't get to
> the debugger port (no matter what I set it to, apparently).
>
> Is there some critical element I'm missing in the configuration changes that
> would allow me to see the actual exception root cause?
Generally speaking, any exception whose stack trace is being dumped will
include the "root cause", its own stack trace, and so on down the line.
This looks like a SpringBoot exception being thrown from SpringBoot
code. It's up to SB to wire-in any "root cause" to the exception being
thrown.
When you have enabled Tomcat logging and raised the log level (e.g. to
TRACE), what are the last messages you can see in the log before the
exception?
Are you able to compare that to the logs that you get on your (working)
Desktop environment?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org>
For additional commands, e-mail:
users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org>
