mirror of
https://github.com/spring-projects/spring-framework.git
synced 2026-09-17 08:24:13 +00:00
Merge branch '7.0.x'
This commit is contained in:
Sam Brannen
@@ -10,7 +10,7 @@ of advice parameters.
|
||||
|
||||
To use the aop namespace tags described in this section, you need to import the
|
||||
`spring-aop` schema, as described in xref:core/appendix/xsd-schemas.adoc[XML Schema-based configuration]
|
||||
. See xref:core/appendix/xsd-schemas.adoc#aop[the AOP schema]
|
||||
. See xref:core/appendix/xsd-schemas.adoc#xsd-schemas-aop[the AOP schema]
|
||||
for how to import the tags in the `aop` namespace.
|
||||
|
||||
Within your Spring configurations, all aspect and advisor elements must be placed within
|
||||
|
||||
@@ -14,11 +14,11 @@ Spring distribution, you should first read the previous section on xref:core/app
|
||||
|
||||
To create new XML configuration extensions:
|
||||
|
||||
. xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-schema[Author] an XML schema to describe your custom element(s).
|
||||
. xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-namespacehandler[Code] a custom `NamespaceHandler` implementation.
|
||||
. xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-parser[Code] one or more `BeanDefinitionParser` implementations
|
||||
. xref:core/appendix/xml-custom.adoc#xsd-custom-schema[Author] an XML schema to describe your custom element(s).
|
||||
. xref:core/appendix/xml-custom.adoc#xsd-custom-namespacehandler[Code] a custom `NamespaceHandler` implementation.
|
||||
. xref:core/appendix/xml-custom.adoc#xsd-custom-parser[Code] one or more `BeanDefinitionParser` implementations
|
||||
(this is where the real work is done).
|
||||
. xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-registration[Register] your new artifacts with Spring.
|
||||
. xref:core/appendix/xml-custom.adoc#xsd-custom-registration[Register] your new artifacts with Spring.
|
||||
|
||||
For a unified example, we create an
|
||||
XML extension (a custom XML element) that lets us configure objects of the type
|
||||
@@ -553,7 +553,7 @@ Kotlin::
|
||||
|
||||
This works nicely, but it exposes a lot of Spring plumbing to the end user. What we are
|
||||
going to do is write a custom extension that hides away all of this Spring plumbing.
|
||||
If we stick to xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-introduction[the steps described previously], we start off
|
||||
If we stick to xref:core/appendix/xml-custom.adoc#xsd-custom-introduction[the steps described previously], we start off
|
||||
by creating the XSD schema to define the structure of our custom tag, as the following
|
||||
listing shows:
|
||||
|
||||
@@ -580,7 +580,7 @@ listing shows:
|
||||
</xsd:schema>
|
||||
----
|
||||
|
||||
Again following xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-introduction[the process described earlier],
|
||||
Again following xref:core/appendix/xml-custom.adoc#xsd-custom-introduction[the process described earlier],
|
||||
we then create a custom `NamespaceHandler`:
|
||||
|
||||
[tabs]
|
||||
|
||||
@@ -179,7 +179,7 @@ infrastructure.
|
||||
|
||||
NOTE: The preceding definition of the `dataSource` bean uses the `<jndi-lookup/>` tag
|
||||
from the `jee` namespace. For more information see
|
||||
xref:integration/appendix.adoc#xsd-schemas-jee[The JEE Schema].
|
||||
xref:integration/appendix.adoc#appendix.xsd-schemas-jee[The JEE Schema].
|
||||
|
||||
NOTE: If you use JTA, your transaction manager definition should look the same, regardless
|
||||
of what data access technology you use, be it JDBC, Hibernate JPA, or any other supported
|
||||
|
||||
@@ -139,8 +139,8 @@ xref:integration/rest-clients.adoc#rest-restclient[`RestClient`] and `RestTestCl
|
||||
the same API up to the point of the call to `exchange()`. After that, `RestTestClient`
|
||||
provides two alternative ways to verify the response:
|
||||
|
||||
1. xref:resttestclient-workflow[Built-in Assertions] extend the request workflow with a chain of expectations
|
||||
2. xref:resttestclient-assertj[AssertJ Integration] to verify the response via `assertThat()` statements
|
||||
1. xref:testing/resttestclient.adoc#resttestclient.workflow[Built-in Assertions] extend the request workflow with a chain of expectations
|
||||
2. xref:testing/resttestclient.adoc#resttestclient.assertj[AssertJ Integration] to verify the response via `assertThat()` statements
|
||||
|
||||
TIP: See the xref:integration/rest-clients.adoc#rest-message-conversion[HTTP Message Conversion]
|
||||
section for examples on how to prepare a request with any content, including form data and multipart data.
|
||||
@@ -167,7 +167,7 @@ include-code::./RestClientWorkflowTests[tag=soft-assertions,indent=0]
|
||||
You can then choose to decode the response body through one of the following:
|
||||
|
||||
* `expectBody(Class<T>)`: Decode to single object.
|
||||
* `expectBody()`: Decode to `byte[]` for xref:testing/resttestclient.adoc#resttestclient-json[JSON Content] or an empty body.
|
||||
* `expectBody()`: Decode to `byte[]` for xref:testing/resttestclient.adoc#resttestclient.json[JSON Content] or an empty body.
|
||||
|
||||
|
||||
If the built-in assertions are insufficient, you can consume the object instead and
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
= Context Configuration with Groovy Scripts
|
||||
|
||||
To load an `ApplicationContext` for your tests by using Groovy scripts that use the
|
||||
xref:core/beans/basics.adoc#beans-factory-groovy[Groovy Bean Definition DSL], you can annotate
|
||||
xref:languages/groovy.adoc#beans-factory-groovy[Groovy Bean Definition DSL], you can annotate
|
||||
your test class with `@ContextConfiguration` and configure the `locations` or `value`
|
||||
attribute with an array that contains the resource locations of Groovy scripts. Resource
|
||||
lookup semantics for Groovy scripts are the same as those described for
|
||||
|
||||
@@ -659,7 +659,7 @@ whether to decode the request path nor whether to remove semicolon content for
|
||||
path matching purposes.
|
||||
|
||||
Spring WebFlux also does not support suffix pattern matching, unlike in Spring MVC, where we
|
||||
are also xref:web/webmvc/mvc-controller/ann-requestmapping.adoc#mvc-ann-requestmapping-suffix-pattern-match[recommend] moving away from
|
||||
are also xref:web/webmvc/mvc-controller/ann-requestmapping.adoc#mvc-ann-requestmapping-rfd[recommend] moving away from
|
||||
reliance on it.
|
||||
====
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
[[test]]
|
||||
= Testing
|
||||
[.small]#xref:web-reactive.adoc#webflux-test[See equivalent in the Reactive stack]#
|
||||
[.small]#xref:web/webflux-test.adoc[See equivalent in the Reactive stack]#
|
||||
|
||||
This section summarizes the options available in `spring-test` for Spring MVC applications.
|
||||
|
||||
|
||||
@@ -10,8 +10,7 @@ By default, only the `Accept` header is checked.
|
||||
|
||||
If you must use URL-based content type resolution, consider using the query parameter
|
||||
strategy over path extensions. See
|
||||
xref:web/webmvc/mvc-controller/ann-requestmapping.adoc#mvc-ann-requestmapping-suffix-pattern-match[Suffix Match]
|
||||
and xref:web/webmvc/mvc-controller/ann-requestmapping.adoc#mvc-ann-requestmapping-rfd[Suffix Match and RFD] for
|
||||
xref:web/webmvc/mvc-controller/ann-requestmapping.adoc#mvc-ann-requestmapping-rfd[Suffix Match and RFD] for
|
||||
more details.
|
||||
|
||||
You can customize requested content type resolution, as the following example shows:
|
||||
|
||||
Reference in New Issue
Block a user