You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: