spring-boot: NoClassDefFoundError: org/apache/catalina/Lifecycle$SingleUse during shutdown
Hello.
I’m on 1.4.0.RELEASE.
My app is pretty basic, but what can be important here, I’m using @EnableScheduling.
Often, not always, when I ctrl-c or kill my app (run by ./<jar>.jar) I’m getting below error:
Exception in thread "Thread-2" java.lang.NoClassDefFoundError: org/apache/catalina/Lifecycle$SingleUse
at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:235)
at org.apache.catalina.startup.Tomcat.stop(Tomcat.java:366)
at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainer.stopTomcat(TomcatEmbeddedServletContainer.java:225)
at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainer.stop(TomcatEmbeddedServletContainer.java:277)
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.stopAndReleaseEmbeddedServletContainer(EmbeddedWebApplicationContext.java:306)
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.onClose(EmbeddedWebApplicationContext.java:155)
at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1010)
at org.springframework.context.support.AbstractApplicationContext$2.run(AbstractApplicationContext.java:923)
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 2
- Comments: 24 (6 by maintainers)
Suffering the same issue, but I have a theory for mine: I’m deploying a new jar on top of the existing one before stopping. This will most likely cause problems when the JVM tries to locate the class, if not loaded before, given the classloader reference to the previous jar is now invalid.
Replacing live jar/s used to cause JVM 5/6 SISSEGVs in Solaris. At least this is just an exception.
Very late to the party, but we were encountering the same issue and this was the first Google hit. The problem can be consistently reproduced by replacing the jar (or change the symlink) and then trying to stop it. We are using ansible for deployments and we ensured the boot app was completely stopped before changing the jar: