anchor.diff:  ==== Other notes relating to wildcards
   Please note that `classpath*:` when combined with Ant-style patterns will only work
   reliably with at least one root directory before the pattern starts, unless the actual
  -target files reside in the file system. This means that a pattern like "
  -`classpath*:*.xml`" will not retrieve files from the root of jar files but rather only
  +target files reside in the file system. This means that a pattern like
  +`classpath*:*.xml` will not retrieve files from the root of jar files but rather only
   from the root of expanded directories. This originates from a limitation in the JDK's
   `ClassLoader.getResources()` method which only returns file system locations for a
   passed-in empty string (indicating potential roots to search).
   
  -Ant-style patterns with " `classpath:`" resources are not guaranteed to find matching
  +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.
   This is because a resource such as
   
  
positive.code: 
  ... the resolver follows a more complex but defined procedure to try to resolve the
  wildcard. It produces a Resource for the path up to the last non-wildcard segment and
  obtains a URL from it. If this URL is not a "jar:" URL or container-specific variant
  (e.g. " `zip:`" in WebLogic, " `wsjar`" in WebSphere, etc.), then a `java.io.File` is
  obtained from it and used to resolve the wildcard by traversing the filesystem. In the
  case of a jar URL, the resolver either gets a `java.net.JarURLConnection` from it or
  manually parses the jar URL and then traverses the contents of the jar file to resolve
  
negative.code: settings that might affect the classloader behavior.
  ====
  
  The `classpath*:` prefix can also be combined with a `PathMatcher` pattern in the
  rest of the location path, for example `classpath*:META-INF/*-beans.xml`. In this
  case, the resolution strategy is fairly simple: a `ClassLoader.getResources()` call is
  used on the last non-wildcard path segment to get all the matching resources in the
  class loader hierarchy, and then off each resource the same PathMatcher resolution
  strategy described above is used for the wildcard subpath.
  