Merge branch '2.6.x' into 2.7.x
Closes gh-30528
This commit is contained in:
@@ -453,7 +453,7 @@ The use of placeholders with and without defaults is shown in the following exam
|
||||
description: "${app.name} is a Spring Boot application written by ${username:Unknown}"
|
||||
----
|
||||
|
||||
Assuming that the `username` property has not be set elsewhere, `app.description` will have the value `MyApp is a Spring Boot application written by Unknown`.
|
||||
Assuming that the `username` property has not been set elsewhere, `app.description` will have the value `MyApp is a Spring Boot application written by Unknown`.
|
||||
|
||||
TIP: You can also use this technique to create "`short`" variants of existing Spring Boot properties.
|
||||
See the _<<howto#howto.properties-and-configuration.short-command-line-arguments>>_ how-to for details.
|
||||
|
||||
@@ -52,7 +52,7 @@ include::{docs-java}/howto/testing/slicetests/MyConfiguration.java[]
|
||||
|
||||
For a `@WebMvcTest` for an application with the above `@Configuration` class, you might expect to have the `SecurityFilterChain` bean in the application context so that you can test if your controller endpoints are secured properly.
|
||||
However, `MyConfiguration` is not picked up by @WebMvcTest's component scanning filter because it doesn't match any of the types specified by the filter.
|
||||
You can include the configuration explicitly by annotating the test class with `@Import(MySecurityConfiguration.class)`.
|
||||
You can include the configuration explicitly by annotating the test class with `@Import(MyConfiguration.class)`.
|
||||
This will load all the beans in `MyConfiguration` including the `BasicDataSource` bean which isn't required when testing the web tier.
|
||||
Splitting the configuration class into two will enable importing just the security configuration.
|
||||
|
||||
@@ -66,6 +66,6 @@ include::{docs-java}/howto/testing/slicetests/MySecurityConfiguration.java[]
|
||||
include::{docs-java}/howto/testing/slicetests/MyDatasourceConfiguration.java[]
|
||||
----
|
||||
|
||||
Having a single configuration class can be inefficient when beans of a certain domain needed to be included in slice tests.
|
||||
Having a single configuration class can be inefficient when beans of a certain domain need to be included in slice tests.
|
||||
Instead, structuring the application's configuration as multiple granular classes with beans for a specific domain can enable importing them only for specific slice tests.
|
||||
|
||||
|
||||
@@ -142,7 +142,7 @@ The first step to customizing this feature often involves using the existing mec
|
||||
For that, you can add a bean of type `ErrorAttributes`.
|
||||
|
||||
To change the error handling behavior, you can implement `ErrorWebExceptionHandler` and register a bean definition of that type.
|
||||
Because a `ErrorWebExceptionHandler` is quite low-level, Spring Boot also provides a convenient `AbstractErrorWebExceptionHandler` to let you handle errors in a WebFlux functional way, as shown in the following example:
|
||||
Because an `ErrorWebExceptionHandler` is quite low-level, Spring Boot also provides a convenient `AbstractErrorWebExceptionHandler` to let you handle errors in a WebFlux functional way, as shown in the following example:
|
||||
|
||||
include::code:MyErrorWebExceptionHandler[]
|
||||
|
||||
|
||||
Reference in New Issue
Block a user