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: </http>
  ----
  
  CSRF protection is enabled by default with Java configuration. If you would like to disable CSRF, the corresponding Java configuration can be seen below. Refer to the Javadoc of csrf() for additional customizations in how CSRF protection is configured.
  
  [source,java]
  ----
  
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
  