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: 
  === Hello Web Security Java Configuration
  
  The first step is to create our Spring Security Java Configuration. The configuration creates a Servlet Filter known as the `springSecurityFilterChain` which is responsible for all the security (protecting the application URLs, validating submitted username and passwords, redirecting to the log in form, etc) within your application. You can find the most basic example of a Spring Security Java configuration below:
  
  [[jc-hello-wsca]]
  [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
  