anchor.diff:  Of course, when using `@Configuration` classes, the Java compiler places constraints on
   the configuration model, in that references to other beans must be valid Java syntax.
   
  -Fortunately, solving this problem is simple. Remember that `@Configuration` classes are
  +Fortunately, solving this problem is simple. As <<beans-java-dependencies,we already discussed>>,
  +`@Bean` method can have an arbitrary number of parameters describing the bean
  +dependencies. Let's consider a more real-world scenario with several `@Configuration`
  +classes, each depending on beans declared in the others:
  +
  +[source,java,indent=0]
  +[subs="verbatim,quotes"]
  +----
  +	@Configuration
  +	public class ServiceConfig {
  +
  +		@Bean
  +		public TransferService transferService(AccountRepository accountRepository) {
  +			return new TransferServiceImpl(accountRepository);
  +		}
  +
  +	}
  +
  +	@Configuration
  +	public class RepositoryConfig {
  +
  +		@Bean
  +		public AccountRepository accountRepository(DataSource dataSource) {
  +			return new JdbcAccountRepository(dataSource);
  +		}
  +
  +	}
  +
  +	@Configuration
  +	@Import({ServiceConfig.class, RepositoryConfig.class})
  +	public class SystemTestConfig {
  +
  +		@Bean
  +		public DataSource dataSource() {
  +			// return new DataSource
  +		}
  +
  +	}
  +
  +	public static void main(String[] args) {
  +		ApplicationContext ctx = new AnnotationConfigApplicationContext(SystemTestConfig.class);
  +		// everything wires up across configuration classes...
  +		TransferService transferService = ctx.getBean(TransferService.class);
  +		transferService.transfer(100.00, "A123", "C456");
  +	}
  +----
  +
  +There is another way to achieve the same result. Remember that `@Configuration` classes are
   ultimately just another bean in the container - this means that they can take advantage
   of `@Autowired` injection metadata just like any other bean!
   
  -Let's consider a more real-world scenario with several `@Configuration` classes, each
  -depending on beans declared in the others:
  +[WARNING]
  +====
  +Make sure that the dependencies you inject that way are of the simplest kind only. `@Configuration`
  +classes are processed quite early during the initialization of the context and forcing a
  +dependency to be injected this way may lead to unexpected early initialization. Whenever possible,
  +resort to parameter-based injection as in the example above.
  +====
   
   [source,java,indent=0]
   [subs="verbatim,quotes"]
  
positive.code: ----
  
  
  [[beans-java-lifecycle-callbacks]]
  ==== Receiving lifecycle callbacks
  Any classes defined with the `@Bean` annotation support the regular lifecycle callbacks
  
negative.code: 	</beans>
  ----
  
  .Full @Configuration vs 'lite' @Beans mode?
  ****
  When `@Bean` methods are declared within classes that are __not__ annotated with
  