|
Sort Order:
I like the annotation living on the parameter as the example given requires needless methods being created (the url, username and password methods).
I understand that the implementation of those methods could provide a default value, but as it stands they are just extra noise. OTOH you could argue (from a relatively academic POV) that where username comes from has nothing to do with consumers of username, so having those extra methods is arguably cleaner. Why not both? @ExternalValue is now supported as a parameter annotation to @Configuration class constructors or @Bean methods.
See latest nightly build documentation for details: http://static.springframework.org/spring-javaconfig/site/spring-javaconfig/reference/html/new-and-noteworthy.html#new-and-noteworthy-1.0.0.m4 Attaching final task context
This functionality has been removed as part of the refactoring effort in
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
New Feature
Resolved
Minor
Support @Bean method parameter annotations for PropertyPlaceholderConfigurer-style injection
There is actually new support in the forthcoming M3 for @ResourceBundles and @ExternalValue, which goes a little something like this:
@Configuration
@ResourceBundles("classpath:/com/myco/datasource")
class MyConfig {
@Bean
public DataSource dataSource() {
return new FooDataSource(url(), username(), password());
}
@ExternalValue("datasource.url")
abstract String url();
@ExternalValue("datasource.username")
abstract String username();
@ExternalValue("datasource.password")
abstract String password();
}
So then: there must be present a com/myco/datasource.properties file in the classpath, with datasource.url, etc name/value pairs.
With that said, I really like your idea, and it's somewhat related to issues
SJC-50,SJC-51andSJC-16. I've added this New Feature request so it can be properly considered.