anchor.diff:  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
  +`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.
   
  
positive.code: [NOTE]
  ====
  The scanning of classpath packages requires the presence of corresponding directory
  entries in the classpath. When you build JARs with Ant, do not activate the files-only
  switch of the JAR task. Also, classpath directories may not get exposed based on security
  policies in some environments -- for example, stand-alone applications on JDK 1.7.0_45
  and higher (which requires 'Trusted-Library' to be set up in your manifests. See
  
negative.code: 	val ctx = FileSystemXmlApplicationContext("classpath:conf/appContext.xml")
  ----
  
  Using `FileSystemXmlApplicationContext` loads the bean definitions from the classpath.
  However, it is still a `FileSystemXmlApplicationContext`. If it is subsequently used as a
  `ResourceLoader`, any unprefixed paths are still treated as filesystem paths.
  
  
  [[resources-app-ctx-classpathxml]]
  