John Hendrikx opened SPR-15290 and commented
Assume I have two classes that will conflict if they were annotated as @Component
and you want a project to select one or the other (making a conscious decision and not providing a default option), ie:
// Option 1:
public class DatabaseBasedLocationProvider implements LocationProvider;
// Option 2:
public class RestBasedLocationProvider implements LocationProvider;
Now, in the client project's configuration (that depends on the project that needs LocationProvider) I want to say:
@BeanClass
Class<LocationProvider> getLocationProviderClass() {
return RestBasedLocationProvider.class; // Please construct and inject!
}
I donot want to construct it myself (and being forced to deal with its dependencies).
The closest I managed to get was doing this in the @Configuration
class:
@Component
public static class MyRestBasedLocationProvider extends RestBasedLocationProvider {
// leave empty, this is just to trick Spring into constructing this bean!
}
A new kind of annotation or option would be so much nicer to achieve this kind of dependency, and enforcing proper configuration of dependent projects.
No further details from SPR-15290
Comment From: snicoll
That's exactly what @Qualifier
is all about. If you're ok to specify the class to use in some configuration arrangement, you can also specify the qualifier when injecting the dependency. This has the advantage to be co-located with the code that requires the bean. Custom qualifier can be developed to make it more declarative.