anchor.diff:  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.
  +Such a resource may exist in only one location in the classpath, 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 desired resource may not exist in the first
  +location found. Therefore, in such cases you should prefer using `classpath*:` with the
  +same Ant-style pattern, which searches all classpath locations that contain the
  +`com.mycompany` base package: `classpath*:com/mycompany/**/service-context.xml`.
   
   
   
  
positive.code: == Resources as Dependencies
  
  If the bean itself is going to determine and supply the resource path through some sort
  of dynamic process, it probably makes sense for the bean to use the `ResourceLoader`
  interface to load resources. For example, consider the loading of a template of some
  sort, where the specific resource that is needed depends on the role of the user. If the
  resources are static, it makes sense to eliminate the use of the `ResourceLoader`
  interface completely, have the bean expose the `Resource` properties it needs,
  and expect them to be injected into it.
  
  What makes it trivial to then inject these properties is that all application contexts
  register and use a special JavaBeans `PropertyEditor`, which can convert `String` paths
  
negative.code: 	</bean>
  ----
  
  Note that the resource path has no prefix. Consequently, because the application context
  itself is going to be used as the `ResourceLoader`, the resource is loaded through a
  `ClassPathResource`, a `FileSystemResource`, or a `ServletContextResource`, depending on
  the exact type of the application context.
  
  If you need to force a specific `Resource` type to be used, you can use a prefix. The
  following two examples show how to force a `ClassPathResource` and a `UrlResource` (the
  latter being used to access a file in the filesystem):
  
  [source,xml,indent=0,subs="verbatim,quotes"]
  ----
  