anchor.diff:  ----
   
   
  +[[beans-java-dependencies]]
  +==== Bean dependencies
  +A `@Bean` annotated method can have an arbitrary number of parameters describing the
  +dependencies required to build that bean. For instance if our `TransferService`
  +requires an `AccountRepository` we can materialize that dependency via a method
  +parameter:
  +
  +[source,java,indent=0]
  +[subs="verbatim,quotes"]
  +----
  +	@Configuration
  +	public class AppConfig {
  +
  +		@Bean
  +		public TransferService transferService(AccountRepository accountRepository) {
  +			return new TransferServiceImpl(accountRepository);
  +		}
  +
  +	}
  +----
  +
  +The resolution mechanism is pretty much identical to constructor-based dependency
  +injection, see <<beans-constructor-injection,the relevant section>> for more details.
  +
  +
   [[beans-java-lifecycle-callbacks]]
   ==== Receiving lifecycle callbacks
   Any classes defined with the `@Bean` annotation support the regular lifecycle callbacks
  
positive.code: 	</beans>
  ----
  
  The `@Bean` and `@Configuration` annotations will be discussed in depth in the sections
  below. First, however, we'll cover the various ways of creating a spring container using
  Java-based configuration.
  
  .Full @Configuration vs 'lite' @Beans mode?
  ****
  When `@Bean` methods are declared within classes that are __not__ annotated with
  
negative.code: hard to track down when operating in 'lite' mode.
  ****
  
  The `@Bean` and `@Configuration` annotations will be discussed in depth in the sections
  below. First, however, we'll cover the various ways of creating a spring container using
  Java-based configuration.
  
  [[beans-java-instantiating-container]]
  === Instantiating the Spring container using AnnotationConfigApplicationContext
  