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
Copy file name to clipboardExpand all lines: src/main/antora/modules/ROOT/pages/repositories/custom-implementations.adoc
+24-17
Original file line number
Diff line number
Diff line change
@@ -241,12 +241,14 @@ XML::
241
241
[[repositories.spring-factories]]
242
242
==== Registering Fragments with spring.factories
243
243
244
-
As already mentioned in the <<repositories.configuration>> section, the infrastructure only auto detects fragments within the repositories base package. Therefore fragments residing in another location or maybe contributed by an external archive will not be found if they do not share a common namespace.
244
+
As already mentioned in the <<repositories.configuration>> section, the infrastructure only auto-detects fragments within the repository base-package.
245
+
Therefore, fragments residing in another location or want to be contributed by an external archive will not be found if they do not share a common namespace.
245
246
Registering fragments within `spring.factories` allows you to circumvent this restriction as explained in the following section.
246
247
247
248
Imagine you'd like to provide some custom search functionality usable across multiple repositories for your organization leveraging a text search index.
248
249
249
-
First all you need is the fragment interface. Please note the generic `<T>` parameter to align the fragment with the repository domain type.
250
+
First all you need is the fragment interface.
251
+
Note the generic `<T>` parameter to align the fragment with the repository domain type.
250
252
251
253
====
252
254
[source,java]
@@ -260,7 +262,8 @@ public interface SearchExtension<T> {
260
262
----
261
263
====
262
264
263
-
Let's assume the actual full text search is available via a `SearchService` that is registered as a `Bean` within the context so we can consume it in our `SearchExtension` implementation. All we need to run the search is the collection/index name and a object mapper that converts the search results into actual domain objects as sketched out below.
265
+
Let's assume the actual full-text search is available via a `SearchService` that is registered as a `Bean` within the context so you can consume it in our `SearchExtension` implementation.
266
+
All you need to run the search is the collection (or index) name and an object mapper that converts the search results into actual domain objects as sketched out below.
In the snipped above we use `RepositoryMethodContext.currentMethod()` to get hold of metadata for the actual method invocation. In doing so we can access additional information attached to the repository. In this case we use the repositories domain type to identify the name of the index to be searched.
302
+
In the example above `RepositoryMethodContext.currentMethod()` is used to retrieve metadata for the actual method invocation.
303
+
`RepositoryMethodContext` exposes information attached to the repository such as the domain type.
304
+
In this case we use the repository domain type to identify the name of the index to be searched.
300
305
301
-
Now that we've got both, the fragments declaration and implementation we can register it in the `META-INF/spring.factories` file, package things up if needed and we're almost good to go.
306
+
Now that you've got both, the fragment declaration and implementation you can register it in the `META-INF/spring.factories` file, package things up if needed, and you're good to go.
302
307
308
+
.Registering a fragment implementation through `META-INF/spring.factories`
Since we're using additional metadata, that comes with additional cost, via `RepositoryMethodContext.currentMethod()` we need to advise the repository factory responsible for creating the actual repository to expose method metadata by setting the `exposeMetadata` flag.
316
+
Exposing invocation metadata is costly, hence it is disabled by default.
317
+
To access `RepositoryMethodContext.currentMethod()` you need to advise the repository factory responsible for creating the actual repository to expose method metadata by setting the `exposeMetadata` flag.
class MyConfiguration implements BeanPostProcessor {
322
329
323
330
@Bean
324
-
public BeanPostProcessor exposeMethodMetadata() {
331
+
static BeanPostProcessor exposeMethodMetadata() {
325
332
326
333
return new BeanPostProcessor() {
327
334
@@ -336,12 +343,13 @@ class Cfg implements BeanPostProcessor {
336
343
}
337
344
}
338
345
----
339
-
The above snippet outlines how to set the `exposeMetadata` flag using a `BeanPostProcessor`.
340
-
Please do not just copy/paste the above but think about your actual use case which may require a more fine grained approach as the above will simply enable the flag on each and every repository. You may want to have a look at our https://github.com/spring-projects/spring-data-examples/tree/main/bom[spring-data-examples] project to draw inspiration.
346
+
347
+
The above example outlines how to enable metadata exposure by setting the `exposeMetadata` flag using a `BeanPostProcessor`.
348
+
Please do not just copy/paste the above but consider your actual use case which may require a more fine-grained approach as the above will simply enable the flag on every repository.
349
+
You may want to have a look at our https://github.com/spring-projects/spring-data-examples/tree/main/bom[spring-data-examples] project to draw inspiration.
341
350
====
342
351
343
-
Now we are ready to make use of the extension.
344
-
Simply add the interface to the repository.
352
+
Now you are ready to make use of your extension; Simply add the interface to your repository:
0 commit comments