anchor.diff:  parameter does exist, the listener separates the `String` by using predefined
   delimiters (comma, semicolon, and whitespace) and uses the values as locations where
   application contexts are searched. Ant-style path patterns are supported as well.
  -Examples are `/WEB-INF/{asterisk}Context.xml` (for all files with names that end with `Context.xml`
  -and that reside in the `WEB-INF` directory) and `/WEB-INF/**/*Context.xml`( for all such files
  -in any subdirectory of `WEB-INF`).
  +Examples are `/WEB-INF/{asterisk}Context.xml` (for all files with names that end with
  +`Context.xml` and that reside in the `WEB-INF` directory) and `/WEB-INF/**/*Context.xml`
  +(for all such files in any subdirectory of `WEB-INF`).
   
   
   
  
positive.code: . Drop the resulting RAR file into your
  application server's deployment directory.
  
  NOTE: Such RAR deployment units are usually self-contained. They do not expose components to
  the outside world, not even to other modules of the same application. Interaction with a
  RAR-based `ApplicationContext` usually occurs through JMS destinations that it shares with
  other modules. A RAR-based `ApplicationContext` may also, for example, schedule some jobs
  or react to new files in the file system (or the like). If it needs to allow synchronous
  access from the outside, it could (for example) export RMI endpoints, which may
  be used by other application modules on the same machine.
  
  
  
  
negative.code:   describes all the beans. Configuration metadata can be specified by XML, Java code, or
    annotations.
  * For each bean, its dependencies are expressed in the form of properties, constructor
    arguments, or arguments to the static-factory method (if you use that instead of a
    normal constructor). These dependencies are provided to the bean, when the bean is
    actually created.
  * Each property or constructor argument is an actual definition of the value to set, or
    a reference to another bean in the container.
  