Align documentation with changes made during 4.1's development

Signed-off-by: Doehyun Baek <doehyunbaek@gmail.com>

See gh-50800
This commit is contained in:
Doehyun Baek
2026-06-24 15:44:05 +01:00
committed by Andy Wilkinson
parent 3a5f796432
commit f7c2c0b2a6
8 changed files with 9 additions and 13 deletions
@@ -26,8 +26,6 @@ include::example$running/devtools-pom.xml[tags=devtools]
When `devtools` is running, it detects changes when you recompile your application and automatically refreshes it.
This works for not only resources but code as well.
It also provides a LiveReload server so that it can automatically trigger a browser refresh whenever things change.
Devtools can also be configured to only refresh the browser whenever a static resource has changed (and ignore any change in the code).
Just include the following property in your project:
@@ -10,14 +10,12 @@ This section answers questions about how it works.
== Reload Static Content
There are several options for hot reloading.
The recommended approach is to use xref:reference:using/devtools.adoc[`spring-boot-devtools`], as it provides additional development-time features, such as support for fast application restarts and LiveReload as well as sensible development-time configuration (such as template caching).
The recommended approach is to use xref:reference:using/devtools.adoc[`spring-boot-devtools`], as it provides additional development-time features, such as support for fast application restarts as well as sensible development-time configuration (such as template caching).
Devtools works by monitoring the classpath for changes.
This means that static resource changes must be "built" for the change to take effect.
By default, this happens automatically in Eclipse when you save your changes.
In IntelliJ IDEA, the Make Project command triggers the necessary build.
Due to the xref:reference:using/devtools.adoc#using.devtools.restart.excluding-resources[default restart exclusions], changes to static resources do not trigger a restart of your application.
They do, however, trigger a live reload.
Alternatively, running in an IDE (especially with debugging on) is a good way to do development (all modern IDEs allow reloading of static resources and usually also allow hot-swapping of Java class changes).
Finally, the xref:build-tool-plugin:index.adoc[Maven and Gradle plugins] can be configured (see the `addResources` property) to support running from the command line with reloading of static files directly from source.
@@ -129,7 +129,7 @@ The following service connections are currently supported:
| Containers named "rabbitmq" with container port 5672 mapped
| javadoc:org.springframework.boot.amqp.autoconfigure.RabbitStreamConnectionDetails[]
| Containers named "rabbitmq" with container port 5552 mapped
| Containers named "rabbitmq" with container port 5552 mapped, or port 5551 mapped when SSL is configured
| javadoc:org.springframework.boot.data.redis.autoconfigure.DataRedisConnectionDetails[]
| Containers named "redis", "redis/redis-stack" or "redis/redis-stack-server"
@@ -215,7 +215,7 @@ As a result, specific configuration keys (such as `logback.configurationFile` fo
[[features.logging.file-rotation]]
== File Rotation
If you are using Logback of Log4J2, it is possible to fine-tune log rotation settings using your `application.properties` or `application.yaml` file.
If you are using Logback or Log4j2, it is possible to fine-tune log rotation settings using your `application.properties` or `application.yaml` file.
For all other logging system, you will need to configure rotation settings directly yourself.
The following rotation policy properties are supported for Logback:
@@ -124,8 +124,8 @@ For production environments, consider using a javadoc:org.springframework.securi
[[security.oauth2.client.common-providers]]
=== OAuth2 Client Registration for Common Providers
For common OAuth2 and OpenID providers (Google, Github, Facebook, and Okta), we provide a set of provider defaults.
The IDs of these common providers are `google`, `github`, `facebook`, and `okta`, respectively.
For common OAuth2 and OpenID providers (Google, Github, Facebook, X, and Okta), we provide a set of provider defaults.
The IDs of these common providers are `google`, `github`, `facebook`, `x`, and `okta`, respectively.
If you do not need to customize these providers, set the registration's `provider` property to the ID of one of the common providers.
Alternatively, you can xref:security/oauth2.adoc#security.oauth2.client[use a registration ID that matches the ID of the provider].
@@ -740,11 +740,11 @@ TIP: A list of the auto-configuration settings that are enabled by javadoc:org.s
The specific beans that you want to test should be specified by using the `value` or `components` attribute of javadoc:org.springframework.boot.restclient.test.autoconfigure.RestClientTest[format=annotation].
When using a javadoc:org.springframework.boot.restclient.RestTemplateBuilder[] in the beans under test and `RestTemplateBuilder.rootUri(String rootUri)` has been called when building the javadoc:org.springframework.web.client.RestTemplate[], then the root URI should be omitted from the javadoc:org.springframework.test.web.client.MockRestServiceServer[] expectations as shown in the following example:
When using a javadoc:org.springframework.boot.restclient.RestTemplateBuilder[] in the beans under test and `RestTemplateBuilder.baseUri(String baseUri)` has been called when building the javadoc:org.springframework.web.client.RestTemplate[], then the base URI should be omitted from the javadoc:org.springframework.test.web.client.MockRestServiceServer[] expectations as shown in the following example:
include-code::MyRestTemplateServiceTests[]
When using a javadoc:org.springframework.web.client.RestClient$Builder[] in the beans under test, or when using a javadoc:org.springframework.boot.restclient.RestTemplateBuilder[] without calling `rootUri(String rootURI)`, the full URI must be used in the javadoc:org.springframework.test.web.client.MockRestServiceServer[] expectations as shown in the following example:
When using a javadoc:org.springframework.web.client.RestClient$Builder[] in the beans under test, or when using a javadoc:org.springframework.boot.restclient.RestTemplateBuilder[] without calling `baseUri(String baseUri)`, the full URI must be used in the javadoc:org.springframework.test.web.client.MockRestServiceServer[] expectations as shown in the following example:
include-code::MyRestClientServiceTests[]
@@ -200,7 +200,7 @@ For example, a javadoc:{url-testcontainers-postgresql-javadoc}/org.testcontainer
If you want to create only a subset of the applicable types, you can use the `type` attribute of javadoc:org.springframework.boot.testcontainers.service.connection.ServiceConnection[format=annotation].
To create a javadoc:org.springframework.boot.amqp.autoconfigure.RabbitStreamConnectionDetails[] bean from a javadoc:{url-testcontainers-rabbitmq-javadoc}/org.testcontainers.rabbitmq.RabbitMQContainer[], you must opt in using the `type` attribute of javadoc:org.springframework.boot.testcontainers.service.connection.ServiceConnection[format=annotation].
The container must also expose port 5552, the RabbitMQ streams port.
The container must also expose port 5552, or port 5551 when SSL is configured, for RabbitMQ Streams.
====
By default `Container.getDockerImageName().getRepository()` is used to obtain the name used to find connection details.
@@ -79,7 +79,7 @@ public class OAuth2ClientProperties implements InitializingBean {
/**
* Reference to the OAuth 2.0 provider to use. May reference one of the common
* providers (google, github, facebook, okta) or the ID of a custom provider
* providers (google, github, facebook, x, okta) or the ID of a custom provider
* configured using 'spring.security.oauth2.client.provider.&lt;id&gt;.*'
* properties. When not set, the ID of this registration is used to identify the
* provider.