anchor.diff:  ====
   
   Ant-style patterns with `classpath:` resources are not guaranteed to find matching
  -resources if the root package to search is available in multiple class path locations.
  +resources if the root package to search is available in multiple classpath locations.
   Consider the following example of a resource location:
   
   [literal,subs="verbatim,quotes"]
  
positive.code: classpath:com/mycompany/**/service-context.xml
  ----
  
  Such a resource may be in only one location, but when a path such as the preceding example
  is used to try to resolve it, the resolver works off the (first) URL returned by
  `getResource("com/mycompany");`. If this base package node exists in multiple
  `ClassLoader` locations, the actual end resource may not be there. Therefore, in such a case
  you should prefer using `classpath*:` with the same Ant-style pattern, which
  searches all class path locations that contain the root package.
  
  
  
  
negative.code: [[resources-app-ctx-portability]]
  ===== Implications on Portability
  
  If the specified path is already a `file` URL (either implicitly because the base
  `ResourceLoader` is a filesystem one or explicitly), wildcarding is guaranteed to
  work in a completely portable fashion.
  
  If the specified path is a `classpath` location, the resolver must obtain the last
  non-wildcard path segment URL by making a `Classloader.getResource()` call. Since this
  is just a node of the path (not the file at the end), it is actually undefined (in the
  `ClassLoader` javadoc) exactly what sort of a URL is returned in this case. In practice,
  