anchor.diff:  Specifying all aliases where the bean is actually defined is not always adequate,
   however. It is sometimes desirable to introduce an alias for a bean that is defined
   elsewhere. This is commonly the case in large systems where configuration is split
  -amongst each subsystem, with each subsystem having its own set of object definitions. In
  -XML-based configuration metadata, you can use the `<alias/>` element to accomplish this.
  -The following example shows how to do so:
  +amongst each subsystem, with each subsystem having its own set of object definitions.
  +In XML-based configuration metadata, you can use the `<alias/>` element to accomplish
  +this. The following example shows how to do so:
   
   ====
   [source,xml,indent=0]
  
positive.code: In this case, a bean (in the same container) named `fromName` may also,
  after the use of this alias definition, be referred to as `toName`.
  
  For example, the configuration metadata for subsystem A may refer to a DataSource by
  the name of `subsystemA-dataSource`. The configuration metadata for subsystem B may refer to
  a DataSource by the name of `subsystemB-dataSource`. When composing the main application
  that uses both these subsystems, the main application refers to the DataSource by the
  name of `myApp-dataSource`. To have all three names refer to the same object, you can add
  the following alias definitions to the configuration metadata:
  
  ====
  [source,xml,indent=0]
  [subs="verbatim,quotes"]
  ----
  	<alias name="subsystemA-dataSource" alias="subsystemB-dataSource"/>
  	<alias name="subsystemA-dataSource" alias="myApp-dataSource" />
  ----
  ====
  
  
negative.code: 	@Configuration
  	public class AppConfig {
  
  		@Bean({"dataSource", "subsystemA-dataSource", "subsystemB-dataSource"})
  		public DataSource dataSource() {
  			// instantiate, configure and return DataSource bean...
  		}
  