I have a Spring Boot application that works as expected when ran with embedded tomcat, but I noticed that if I try to run it from an existing tomcat instance that I'm using with a previous project then it fails with a NoClassDefFoundError for a class that I don't use anywhere in my application.

I noticed in the /lib directory I had a single jar that contained a few Spring annotated classes, so as a test I cleaned out the /lib directory which resolved the issue. My assumption is that Spring is seeing some of the configurations/beans/imports on the classpath due to them existing in the /lib directory and either trying to autoconfigure something on its own, or is actually trying to instantiate some of these classes.

So then my question is - assuming I can't always fully control the contents of everything on the classpath, how can I prevent errors like this from occurring?

EDIT

For a little more detail - the class not being found is DefaultCookieSerializer which is part of the spring-session-implementation dependency. It is pulled into one of the classes in the jar located in /lib, but it is not any part of my application.

CodePudding user response：

Check for features provided by @EnableAutoConfiguration. You can explicitly configure set of auto-configuration classes for your application. This tutorial can be a good starting point.

CodePudding user response：

The likely culprit of mentioned exception are incompatible jars on the classpath.

As we don't know with what library you have the issue we cant tell you the exact reason, but the situation looks like that:

1. One of Spring-Boot autoconfiguration classes is being triggered by the presence of class on the classpath
2. Trigerred configuration tries to create some bean of class that is not present in the jar you have (but it is in the specific version mentioned in the Spring BOM)

Version incompatibilities may also cause MethodNotFound exceptions.

That's one of the reasons why it is good practice not to run Spring Boot applications inside the container (make jar not war), but as a runnable jar with an embedded container.

Even before Spring Boot it was preferred to take account of libraries being present on runtime classpath and mark them as provided inside your project. Having different versions of the library on a classpath may cause weird ClassCastExceptions where on both ends names match, but the rest doesn't.

You could resolve specific cases by disabling autoconfiguration that causes your issue. You can do that either by adding exclude to your @SpringBootApplication or using a property file.