Polishing.

This commit is contained in:
Greg L. Turnquist
2023-07-20 09:54:22 -05:00
parent 988888d3be
commit b8009acaf8
4 changed files with 4 additions and 4 deletions

View File

@@ -16,7 +16,7 @@ See "`xref:repository-query-return-types-reference.adoc[Repository query return
[[repositories.nullability.annotations]]
== Nullability Annotations
You can express nullability constraints for repository methods by using {spring-framework-docs}/core.html#null-safety[Spring Framework's nullability annotations].
You can express nullability constraints for repository methods by using {spring-framework-docs}/core/null-safety.html[Spring Framework's nullability annotations].
They provide a tooling-friendly approach and opt-in `null` checks during runtime, as follows:
* {spring-framework-javadoc}/org/springframework/lang/NonNullApi.html[`@NonNullApi`]: Used on the package level to declare that the default behavior for parameters and return values is, respectively, neither to accept nor to produce `null` values.

View File

@@ -439,7 +439,7 @@ The type to which the JSON object is unmarshalled is determined by inspecting th
The infrastructure eventually selects the appropriate repository to handle the object that was deserialized.
To instead use XML to define the data the repositories should be populated with, you can use the `unmarshaller-populator` element.
You configure it to use one of the XML marshaller options available in Spring OXM. See the {spring-framework-docs}/data-access.html#oxm[Spring reference documentation] for details.
You configure it to use one of the XML marshaller options available in Spring OXM. See the {spring-framework-docs}/data-access/oxm.html[Spring reference documentation] for details.
The following example shows how to unmarshall a repository populator with JAXB:
.Declaring an unmarshalling repository populator (using JAXB)

View File

@@ -65,7 +65,7 @@ By default, the infrastructure picks up every interface that extends the persist
However, you might want more fine-grained control over which interfaces have bean instances created for them.
To do so, use filter elements inside the repository declaration.
The semantics are exactly equivalent to the elements in Spring's component filters.
For details, see the {spring-framework-docs}/core.html#beans-scanning-filters[Spring reference documentation] for these elements.
For details, see the {spring-framework-docs}/core/beans/classpath-scanning.html[Spring reference documentation] for these elements.
For example, to exclude certain interfaces from instantiation as repository beans, you could use the following configuration:

View File

@@ -247,7 +247,7 @@ NOTE: Not all Spring Data modules currently support `Stream<T>` as a return type
[[repositories.query-async]]
== Asynchronous Query Results
You can run repository queries asynchronously by using {spring-framework-docs}/integration.html#scheduling[Spring's asynchronous method running capability].
You can run repository queries asynchronously by using {spring-framework-docs}/integration/scheduling.html[Spring's asynchronous method running capability].
This means the method returns immediately upon invocation while the actual query occurs in a task that has been submitted to a Spring `TaskExecutor`.
Asynchronous queries differ from reactive queries and should not be mixed.
See the store-specific documentation for more details on reactive support.