Causa principal:

Según Tomcat Wiki , la especificación Servlet 3.0 requiere el escaneo de Jar durante el inicio del servidor.

Tomcat está usando org.apache.tomcat.util.scan. StandardJarScanner para este propósito.

Del javadoc de StandardJarScanner .

La implementación predeterminada de JarScanner escanea el directorio WEB-INF/lib seguido del cargador de clases proporcionado y luego trabaja en la jerarquía del cargador de clases. Esta implementación es suficiente para cumplir con los requisitos de la especificación Servlet 3.0 , así como para proporcionar una serie de extensiones específicas de Tomcat. Las extensiones son:

• Escaneo de la jerarquía del cargador de clases (habilitado de manera predeterminada) Prueba de todos los archivos para ver si son JAR (deshabilitado de manera predeterminada)

• Probando todos los directorios para ver si son JAR explotados (deshabilitados por defecto)

• Todas las extensiones se pueden controlar a través de la configuración .

Solución 1: específica para Spring Boot.

Podemos deshabilitar este escaneo de jar.

Lo deshabilité agregando la siguiente propiedad en el archivo application-xxx.properties. Esta propiedad es específica de Spring Boot .

 # Comma-separated list of additional patterns that match jars to ignore for TLD scanning. server.tomcat.additional-tld-skip-patterns=*.jar

Puede encontrar propiedades similares de Tomcat aquí .

Estas propiedades se pueden usar para configurar aplicaciones tomcat tradicionales (arranque sin resorte).

Solución 2: Primavera específica

Puede deshabilitar el JarScanner para archivos de manifiesto como se muestra a continuación.

 @Bean public EmbeddedServletContainerFactory embeddedServletContainerFactory() { return new TomcatEmbeddedServletContainerFactory() { @Override protected void postProcessContext(Context context) { ((StandardJarScanner) context.getJarScanner()).setScanManifest(false); } }; }

Solución 3: Tomcat independiente tradicional:

 <Context> ... <JarScanner scanManifest="false"/> ... </Context>

Consulte:El componente Jar Scanner .

Solo para mejorar los hallazgos de Sundaraj... deshabilitar completamente el escaneo de TLD romperá el soporte de JSP/JSTL.

El problema es que el classpath en sí está bien, solo Tomcat escanea adicionalmente los archivos de manifiesto de cada Jar, y dado que con Maven cada Jar está en su propio directorio, eso genera rutas sin sentido (¿probablemente ejecutándose desde Eclipse?).

Entonces, si desea seguir usando JSP con JSTL, debe deshabilitar solo el escaneo de manifiesto.

Para Spring Boot 2.0, agregue esto a la configuración de su aplicación:

 @Bean public TomcatServletWebServerFactory tomcatFactory() { return new TomcatServletWebServerFactory() { @Override protected void postProcessContext(Context context) { ((StandardJarScanner) context.getJarScanner()).setScanManifest(false); } }; }

JarScannerFactory cargó StandardJarScanner que debemos configurar aquí , por lo que esto (para Spring Boot 2.1.8) también funciona.

 import org.apache.tomcat.JarScanner; import org.apache.tomcat.util.scan.StandardJarScanner; import org.springframework.boot.web.servlet.ServletContextInitializer; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; @Configuration public class WebContextConfiguration { @Bean public ServletContextInitializer servletContextInitializer() { return context -> context.setAttribute( JarScanner.class.getName(), new StandardJarScanner() {{ setScanManifest(false); }} ); } }