Hi Barry,
SJC-62 is actually resolved. I wonder if you're referring to SJC-50 and SJC-51, both of which deal with allowing parameters to @Bean methods, and both of which are deferred?
Technically speaking, it's possible to allow autowired parameters to @Bean methods - it was actually implemented for a short time. The reason this functionality has been removed is that it doesn't quite make sense. If a @Bean method accepts parameters, it prevents any other @Bean method from referring to it. Consider the following example:
Code:
@Configuration
public class AppConfig {
// DataSource parameter is 'autowired'
public @Bean AccountRepository accountRepository(DataSource dataSource) {
return new JdbcAccountRepository(dataSource);
}
public @Bean TransferService transferService() {
return new TransferService(accountRepository(/* uh-oh! */));
}
}
Notice that transferService() cannot successfully call accountRepository()? It would have to pass along a dataSource parameter as well. This inability for one @Bean method to easily reference another @Bean method violates JavaConfig's basic model for dependency injection. Therefore, we've disallowed @Bean parameters.
The good news is that field autowiring is fully supported in @Configuration classes:
Code:
@Configuration
@AnnotationDrivenConfig
public class AppConfig {
@Autowired
private DataSource dataSource;
public @Bean AccountRepository accountRepository() {
return new JdbcAccountRepository(dataSource);
}
public @Bean TransferService transferService() {
return new TransferService(accountRepository());
}
}
The above works without a problem. Note that support for autowiring (@AnnotationDrivenConfig, @ComponentScan) is fully documented. See the M4 reference documentation for details.