@ -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}"
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.
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.
See the _<<howto#howto.properties-and-configuration.short-command-line-arguments>>_ how-to for details.
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.
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.
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.
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.
Splitting the configuration class into two will enable importing just the security configuration.
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.
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`.
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.
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: