We are migrating a spring boot application from 2.2.4 to 2.4.3
The application can be run with inbuilt tomcat / Tomcat war deployment.
Environment: Windows Azul Java 11 (Zulu 11) and Tomcat 9.0.33
If I run the code with my Netbeans linked tomcat, it works fine.
If I deploy the generated war directly in the same standalone tomcat, it throws the following error.
SEVERE [main] org.apache.catalina.startup.HostConfig.deployWAR Error deploying web application archive [D:\apache-tomcat-9.0.33-without port - rest.war]
java.lang.IllegalStateException: Error starting child
................................................................
................................................................
Caused by: org.springframework.boot.context.config.UnsupportedConfigDataLocationException: Unsupported config data location 'optional:file:./config/*/'
at org.springframework.boot.context.config.ConfigDataLocationResolvers.resolve(ConfigDataLocationResolvers.java:110)
On reading through the Spring document, it was mentioned that By default, Spring Boot includes config/*/ in the default search locations. Ref: https://docs.spring.io/spring-boot/docs/2.4.0-SNAPSHOT/reference/htmlsingle/#boot-features-external-config-files-wildcards
I further debugged with spring boot source and spring core source and identified that there is a mismatch in the classloader that happens that was the cause of this exception.
SpringFactoriesLoader is the class that gets loaded by ParallelWebAppClassLoader in NB linked tomcat and by URLClassLoader in standalone tomcat.
Ref: Line No 129 at https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/main/java/org/springframework/core/io/support/SpringFactoriesLoader.java#L129
The cache at Line 136 has the config classes loaded by ParallelWebAppClassLoader, but not by the URLlassLoader. So the 2 resolvers - ConfigTreeConfigDataLocationResolver, StandardConfigDataLocationResolver in boot v2.4.3 are not getting identified when it tries to retrieve with the key URLlassLoader (Line 136).
Not sure whether this is an issue with Springboot / SpringCore / Tomcat / any new configuration to be added as a part of our upgrade.
Note: Our application.properties has spring.servlet.multipart related properties only.
This was an issue in Spring boot.
Updating to version 2.4.6 will solve this issue.