Using the "classpath:" notation with wildcard filters can lead to non-portable behavior between application platforms.
In Spring based applications, the notation classpath: is used to load the application context files. The resources are identified using the classpath URIs.
Using the wildcard filters in classpath: as shown below
The intent of "classpath:**/applicationContext.xml" was to find the first occurrence of a file named "applicationContext.xml" and process that file. However, that's not really the search performed by Spring.
For example the filter "classpath:foo/bar/**/baz.xml" Spring will obtain a URL using ClassLoader.getResource("foo/bar") and then using that URL, Spring will search for foo/bar/**/baz.html. No other URL's will be searched. This means that Spring will only search a single ClassLoader. So, if multiple jar files, WEB-INF/classes, etc contain "foo/bar", only one ClassLoader will be searched by Spring.
In the case of "classpath:**/applicationContext.xml" Spring will simply choose the first ClassLoader (any ClassLoader will contain a resource that '**') and search that ClassLoader for "applicationsContext.xml". So, that only works if the first ClassLoader Spring sees is the ClassLoader that contains applicationContext.xml.
There's no guarantee that is true. And is not true for some configurations of WebSphere Application Server Community Edition. Spring does not provide error messages/warnings if a contextConfigLocation is not located.
Resolving the problem
"classpath*:**/applicationContext.xml" should obtain all instances of applicationContext.xml.
How does the XML configuration behave if multiple copies of the resource are found?
Document on Wildcards in application context constructor resource paths
Using more explicit filter that will resolve to the appropriate ClassLoader.