Spring/spring-data-commons
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

DATACMNS-552 - Naming conventions for custom repository implementations are now more obvious.

Browse Source 
Added a note to hint to the Impl postfix to be important and refer to the paragraphs following for more details on that,
This commit is contained in:
Oliver Gierke
2014-08-10 14:46:09 +02:00
parent 5d0f581068
commit 3c38218940
1 changed files with 7 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
src/main/asciidoc/repositories.adoc
View File

@@ -414,6 +414,8 @@ class UserRepositoryImpl implements UserRepositoryCustom {
----
====
NOTE: The most important bit for the class to be found is the `Impl` postfix of the name on it compared to the core repository interface (see below).
The implementation itself does not depend on Spring Data and can be a regular Spring bean. So you can use standard dependency injection behavior to inject references to other beans like a JdbTemplate, take part in aspects, and so on.
.Changes to the your basic repository interface
@@ -442,11 +444,13 @@ If you use namespace configuration, the repository infrastructure tries to autod
----
====
The first configuration example will try to look up a class com.acme.repository.UserRepositoryImpl to act as custom repository implementation, whereas the second example will try to lookup com.acme.repository.UserRepositoryFooBar.
The first configuration example will try to look up a class `com.acme.repository.UserRepositoryImpl` to act as custom repository implementation, whereas the second example will try to lookup `com.acme.repository.UserRepositoryFooBar`.
Manual wiring The preceding approach works well if your custom implementation uses annotation-based configuration and autowiring only, as it will be treated as any other Spring bean. If your custom implementation bean needs special wiring, you simply declare the bean and name it after the conventions just described. The infrastructure will then refer to the manually defined bean definition by name instead of creating one itself.
===== Manual wiring
.Manual wiring of custom implementations (I)
The approach just shown works well if your custom implementation uses annotation-based configuration and autowiring only, as it will be treated as any other Spring bean. If your custom implementation bean needs special wiring, you simply declare the bean and name it after the conventions just described. The infrastructure will then refer to the manually defined bean definition by name instead of creating one itself.
.Manual wiring of custom implementations
====
[source, xml]
----