@ -2707,35 +2706,30 @@ you can declare a concrete target `Object`, instead of `Part`, as the following
@@ -2707,35 +2706,30 @@ you can declare a concrete target `Object`, instead of `Part`, as the following
----
<1> Using `@RequestPart` to get the metadata.
You can use `@RequestPart` combination with `javax.validation.Valid` or Spring's
`@Validated` annotation, which causes Standard Bean Validation to be applied.
By default, validation errors cause a `WebExchangeBindException`, which is turned
into a 400 (`BAD_REQUEST`) response. Alternatively, you can handle validation errors locally
within the controller through an `Errors` or `BindingResult` argument, as the following example shows:
You can use `@RequestPart` in combination with `javax.validation.Valid` or Spring's
`@Validated` annotation, which causes Standard Bean Validation to be applied. Validation
errors lead to a `WebExchangeBindException` that results in a 400 (BAD_REQUEST) response.
The exception contains a `BindingResult` with the error details and can also be handled
in the controller method by declaring the argument with an async wrapper and then using
fun handle(@Valid @RequestPart("meta-data") metadata: MetaData, // <1>
result: BindingResult): String { // <2>
fun handle(@Valid @RequestPart("meta-data") metadata: MetaData): String {
// ...
}
----
<1> Using a `@Valid` annotation.
<2> Using a `BindingResult` argument.
To access all multipart data as a `MultiValueMap`, you can use `@RequestBody`,
as the following example shows:
@ -2835,25 +2829,25 @@ You can use the <<webflux-config-message-codecs>> option of the <<webflux-config
@@ -2835,25 +2829,25 @@ You can use the <<webflux-config-message-codecs>> option of the <<webflux-config
configure or customize message readers.
You can use `@RequestBody` in combination with `javax.validation.Valid` or Spring's
`@Validated` annotation, which causes Standard Bean Validation to be applied.
By default, validation errors cause a `WebExchangeBindException`, which is turned
into a 400 (`BAD_REQUEST`) response. Alternatively, you can handle validation errors locally
within the controller through an `Errors` or a `BindingResult` argument. The following
example uses a `BindingResult` argument`:
`@Validated` annotation, which causes Standard Bean Validation to be applied. Validation
errors cause a `WebExchangeBindException`, which results in a 400 (BAD_REQUEST) response.
The exception contains a `BindingResult` with error details and can be handled in the
controller method by declaring the argument with an async wrapper and then using error