anchor.diff:  ----
   ====
   
  -Also, with `@Bean` methods, you typically use programmatic JNDI lookups,
  -either by using Spring's `JndiTemplate` or `JndiLocatorDelegate` helpers or straight JNDI
  +Also, with `@Bean` methods, you typically use programmatic JNDI lookups, either by
  +using Spring's `JndiTemplate` or `JndiLocatorDelegate` helpers or straight JNDI
   `InitialContext` usage but not the `JndiObjectFactoryBean` variant (which would force
   you to declare the return type as the `FactoryBean` type instead of the actual target
   type, making it harder to use for cross-reference calls in other `@Bean` methods that
  
positive.code: This annotation indicates that the affected bean property must be populated at
  configuration time, through an explicit property value in a bean definition or through
  autowiring. The container throws an exception if the affected bean property has not been
  populated. This allows for eager and explicit failure, avoiding `NullPointerException` instances
  or the like later on. We still recommend that you put assertions into the bean
  class itself (for example, into an init method). Doing so enforces those required
  references and values even when you use the class outside of a container.
  
  
  
  
negative.code: ----
  ====
  
  The preceding example has almost exactly the same effect as the following example
  (which consists of two listings):
  
  ====
  [source,xml,indent=0]
  