Merge pull request #30498 from izeye
* gh-30498: Polish documentation Closes gh-30498
This commit is contained in:
		
						commit
						b5a02d9a66
					
				| 
						 | 
				
			
			@ -628,7 +628,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:
 | 
			
		||||
 | 
			
		||||
[source,java,indent=0,subs="verbatim"]
 | 
			
		||||
----
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -456,7 +456,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.
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -61,7 +61,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.
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -75,6 +75,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.
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -44,7 +44,6 @@ import org.springframework.boot.testsupport.compiler.TestCompiler;
 | 
			
		|||
import org.springframework.core.ResolvableType;
 | 
			
		||||
import org.springframework.core.convert.ConversionService;
 | 
			
		||||
import org.springframework.format.annotation.DateTimeFormat;
 | 
			
		||||
import org.springframework.test.util.ReflectionTestUtils;
 | 
			
		||||
import org.springframework.util.Assert;
 | 
			
		||||
 | 
			
		||||
import static org.assertj.core.api.Assertions.assertThat;
 | 
			
		||||
| 
						 | 
				
			
			@ -389,8 +388,8 @@ class ValueObjectBinderTests {
 | 
			
		|||
		compiler.getTask(Arrays.asList(recordProperties)).call();
 | 
			
		||||
		ClassLoader ucl = new URLClassLoader(new URL[] { tempDir.toURI().toURL() });
 | 
			
		||||
		Object bean = this.binder.bind("test.record", Class.forName("RecordProperties", true, ucl)).get();
 | 
			
		||||
		assertThat(ReflectionTestUtils.getField(bean, "property1")).isEqualTo("value-from-config-1");
 | 
			
		||||
		assertThat(ReflectionTestUtils.getField(bean, "property2")).isEqualTo("default-value-2");
 | 
			
		||||
		assertThat(bean).hasFieldOrPropertyWithValue("property1", "value-from-config-1")
 | 
			
		||||
				.hasFieldOrPropertyWithValue("property2", "default-value-2");
 | 
			
		||||
	}
 | 
			
		||||
 | 
			
		||||
	private void noConfigurationProperty(BindException ex) {
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
		Loading…
	
		Reference in New Issue