Since we have 2 implementations of data source (user and core), @autowire does not know how to inject them. Apparently one can inject resources using its name with the @resource annotation. That may be the solution instead of using the DatasourceServiceLocator.
See:
http://stackoverflow.com/questions/4093504/resource-vs-autowired
Both @Autowired (or @Inject) and @resource work equally well. But there is a conceptual difference or a difference in the meaning
@resource means get me a known resource by name. The name is extracted from the name of the annotated setter or field, or it is taken from the name-Parameter.
@Inject or @Autowired try to wire in a suitable other component by type.
So, basically these are two quite distinct concepts. Unfortunately the Spring-Implementation of @resource has a built-in fallback, which kicks in when resolution by-name fails. In this case, it falls back to the @Autowired-kind resolution by-type. While this fallback is convenient, IMHO it causes a lot of confusion, because people are unaware of the conceptual difference and tend to use @resource for type-based autowiring.
Since we have 2 implementations of data source (user and core), @autowire does not know how to inject them. Apparently one can inject resources using its name with the @resource annotation. That may be the solution instead of using the DatasourceServiceLocator.
See:
http://stackoverflow.com/questions/4093504/resource-vs-autowired
Both @Autowired (or @Inject) and @resource work equally well. But there is a conceptual difference or a difference in the meaning
@resource means get me a known resource by name. The name is extracted from the name of the annotated setter or field, or it is taken from the name-Parameter.
@Inject or @Autowired try to wire in a suitable other component by type.
So, basically these are two quite distinct concepts. Unfortunately the Spring-Implementation of @resource has a built-in fallback, which kicks in when resolution by-name fails. In this case, it falls back to the @Autowired-kind resolution by-type. While this fallback is convenient, IMHO it causes a lot of confusion, because people are unaware of the conceptual difference and tend to use @resource for type-based autowiring.