anchor.diff:  
   ==== GlobalMethodSecurityConfiguration
   
  -Sometimes you may need to perform operations that are more complicated than are possible with the `@EnableGlobalMethodSecurity` annotation allow. For these instances, you can extend the `GlobalMethodSecurityConfiguration` ensuring that the `@EnableGlobalMethodSecurity` annotation is present on your subclass. For example, if you wanted to provide a custom `MethodSecurityExpressionHander`, you could use the following configuration:
  +Sometimes you may need to perform operations that are more complicated than are possible with the `@EnableGlobalMethodSecurity` annotation allow. For these instances, you can extend the `GlobalMethodSecurityConfiguration` ensuring that the `@EnableGlobalMethodSecurity` annotation is present on your subclass. For example, if you wanted to provide a custom `MethodSecurityExpressionHandler`, you could use the following configuration:
   
   [source,java]
   ----
  
positive.code: 	@Override
  	protected MethodSecurityExpressionHandler createExpressionHandler() {
  		// ... create and return custom MethodSecurityExpressionHandler ...
  		return expressionHander;
  	}
  }
  ----
  
negative.code: </beans>
  ----
  
  In many of the examples you will see (and in the sample applications), we
  			will often use "security" as the default namespace rather than "beans", which means we
  			can omit the prefix on all the security namespace elements, making the content easier to
  			read. You may also want to do this if you have your application context divided up into
  