diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/ROOT/pages/upgrading.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/ROOT/pages/upgrading.adoc
index 01234a3d4a..2024541396 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/ROOT/pages/upgrading.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/ROOT/pages/upgrading.adoc
@@ -41,7 +41,7 @@ To enable that feature, add the following dependency to your project:
----
-WARNING: Properties that are added late to the environment, such as when using `@PropertySource`, will not be taken into account.
+WARNING: Properties that are added late to the environment, such as when using javadoc:org.springframework.context.annotation.PropertySource[format=annotation], will not be taken into account.
NOTE: Once you finish the migration, please make sure to remove this module from your project's dependencies.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/build-tool-plugin/pages/other-build-systems.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/build-tool-plugin/pages/other-build-systems.adoc
index a0a87bf24b..5636b5f616 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/build-tool-plugin/pages/other-build-systems.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/build-tool-plugin/pages/other-build-systems.adoc
@@ -12,8 +12,8 @@ If you need to, you may use this library directly.
[[build-tool-plugins.other-build-systems.repackaging-archives]]
== Repackaging Archives
-To repackage an existing archive so that it becomes a self-contained executable archive, use `org.springframework.boot.loader.tools.Repackager`.
-The `Repackager` class takes a single constructor argument that refers to an existing jar or war archive.
+To repackage an existing archive so that it becomes a self-contained executable archive, use javadoc:org.springframework.boot.loader.tools.Repackager[].
+The javadoc:org.springframework.boot.loader.tools.Repackager[] class takes a single constructor argument that refers to an existing jar or war archive.
Use one of the two available `repackage()` methods to either replace the original file or write to a new destination.
Various settings can also be configured on the repackager before it is run.
@@ -22,8 +22,8 @@ Various settings can also be configured on the repackager before it is run.
[[build-tool-plugins.other-build-systems.nested-libraries]]
== Nested Libraries
-When repackaging an archive, you can include references to dependency files by using the `org.springframework.boot.loader.tools.Libraries` interface.
-We do not provide any concrete implementations of `Libraries` here as they are usually build-system-specific.
+When repackaging an archive, you can include references to dependency files by using the javadoc:org.springframework.boot.loader.tools.Libraries[] interface.
+We do not provide any concrete implementations of javadoc:org.springframework.boot.loader.tools.Libraries[] here as they are usually build-system-specific.
If your archive already includes libraries, you can use javadoc:org.springframework.boot.loader.tools.Libraries#NONE[].
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/actuator.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/actuator.adoc
index a1c91e76b4..0c10cbc9d3 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/actuator.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/actuator.adoc
@@ -20,20 +20,20 @@ For more detail, see the javadoc:org.springframework.boot.actuate.autoconfigure.
[[howto.actuator.customizing-sanitization]]
== Customizing Sanitization
-To take control over the sanitization, define a `SanitizingFunction` bean.
-The `SanitizableData` with which the function is called provides access to the key and value as well as the `PropertySource` from which they came.
+To take control over the sanitization, define a javadoc:org.springframework.boot.actuate.endpoint.SanitizingFunction[] bean.
+The javadoc:org.springframework.boot.actuate.endpoint.SanitizableData[] with which the function is called provides access to the key and value as well as the javadoc:org.springframework.core.env.PropertySource[] from which they came.
This allows you to, for example, sanitize every value that comes from a particular property source.
-Each `SanitizingFunction` is called in order until a function changes the value of the sanitizable data.
+Each javadoc:org.springframework.boot.actuate.endpoint.SanitizingFunction[] is called in order until a function changes the value of the sanitizable data.
[[howto.actuator.map-health-indicators-to-metrics]]
== Map Health Indicators to Micrometer Metrics
-Spring Boot health indicators return a `Status` type to indicate the overall system health.
+Spring Boot health indicators return a javadoc:org.springframework.boot.actuate.health.Status[] type to indicate the overall system health.
If you want to monitor or alert on levels of health for a particular application, you can export these statuses as metrics with Micrometer.
By default, the status codes "`UP`", "`DOWN`", "`OUT_OF_SERVICE`" and "`UNKNOWN`" are used by Spring Boot.
-To export these, you will need to convert these states to some set of numbers so that they can be used with a Micrometer `Gauge`.
+To export these, you will need to convert these states to some set of numbers so that they can be used with a Micrometer javadoc:io.micrometer.core.instrument.Gauge[].
The following example shows one way to write such an exporter:
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/application.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/application.adoc
index 1c23f05949..d87619032f 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/application.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/application.adoc
@@ -12,11 +12,11 @@ javadoc:org.springframework.boot.diagnostics.FailureAnalyzer[] is a great way to
Spring Boot provides such an analyzer for application-context-related exceptions, JSR-303 validations, and more.
You can also create your own.
-`AbstractFailureAnalyzer` is a convenient extension of `FailureAnalyzer` that checks the presence of a specified exception type in the exception to handle.
+javadoc:org.springframework.boot.diagnostics.AbstractFailureAnalyzer[] is a convenient extension of javadoc:org.springframework.boot.diagnostics.FailureAnalyzer[] that checks the presence of a specified exception type in the exception to handle.
You can extend from that so that your implementation gets a chance to handle the exception only when it is actually present.
If, for whatever reason, you cannot handle the exception, return `null` to give another implementation a chance to handle the exception.
-`FailureAnalyzer` implementations must be registered in `META-INF/spring.factories`.
+javadoc:org.springframework.boot.diagnostics.FailureAnalyzer[] implementations must be registered in `META-INF/spring.factories`.
The following example registers `ProjectConstraintViolationFailureAnalyzer`:
[source,properties]
@@ -25,7 +25,7 @@ org.springframework.boot.diagnostics.FailureAnalyzer=\
com.example.ProjectConstraintViolationFailureAnalyzer
----
-NOTE: If you need access to the `BeanFactory` or the `Environment`, declare them as constructor arguments in your `FailureAnalyzer` implementation.
+NOTE: If you need access to the javadoc:org.springframework.beans.factory.BeanFactory[] or the javadoc:org.springframework.core.env.Environment[], declare them as constructor arguments in your javadoc:org.springframework.boot.diagnostics.FailureAnalyzer[] implementation.
@@ -34,7 +34,7 @@ NOTE: If you need access to the `BeanFactory` or the `Environment`, declare them
The Spring Boot auto-configuration tries its best to "`do the right thing`", but sometimes things fail, and it can be hard to tell why.
-There is a really useful `ConditionEvaluationReport` available in any Spring Boot `ApplicationContext`.
+There is a really useful javadoc:org.springframework.boot.autoconfigure.condition.ConditionEvaluationReport[] available in any Spring Boot javadoc:org.springframework.context.ApplicationContext[].
You can see it if you enable `DEBUG` logging output.
If you use the `spring-boot-actuator` (see the xref:actuator.adoc[] section), there is also a `conditions` endpoint that renders the report in JSON.
Use that endpoint to debug the application and see what features have been added (and which have not been added) by Spring Boot at runtime.
@@ -46,31 +46,31 @@ When reading the code, remember the following rules of thumb:
Pay special attention to the `+@Conditional*+` annotations to find out what features they enable and when.
Add `--debug` to the command line or the System property `-Ddebug` to get a log on the console of all the auto-configuration decisions that were made in your app.
In a running application with actuator enabled, look at the `conditions` endpoint (`/actuator/conditions` or the JMX equivalent) for the same information.
-* Look for classes that are `@ConfigurationProperties` (such as javadoc:org.springframework.boot.autoconfigure.web.ServerProperties[]) and read from there the available external configuration options.
- The `@ConfigurationProperties` annotation has a `name` attribute that acts as a prefix to external properties.
- Thus, `ServerProperties` has `prefix="server"` and its configuration properties are `server.port`, `server.address`, and others.
+* Look for classes that are javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] (such as javadoc:org.springframework.boot.autoconfigure.web.ServerProperties[]) and read from there the available external configuration options.
+ The javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] annotation has a `name` attribute that acts as a prefix to external properties.
+ Thus, javadoc:org.springframework.boot.autoconfigure.web.ServerProperties[] has `prefix="server"` and its configuration properties are `server.port`, `server.address`, and others.
In a running application with actuator enabled, look at the `configprops` endpoint.
-* Look for uses of the `bind` method on the `Binder` to pull configuration values explicitly out of the `Environment` in a relaxed manner.
+* Look for uses of the `bind` method on the javadoc:org.springframework.boot.context.properties.bind.Binder[] to pull configuration values explicitly out of the javadoc:org.springframework.core.env.Environment[] in a relaxed manner.
It is often used with a prefix.
-* Look for `@Value` annotations that bind directly to the `Environment`.
-* Look for `@ConditionalOnExpression` annotations that switch features on and off in response to SpEL expressions, normally evaluated with placeholders resolved from the `Environment`.
+* Look for javadoc:org.springframework.beans.factory.annotation.Value[format=annotation] annotations that bind directly to the javadoc:org.springframework.core.env.Environment[].
+* Look for javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnExpression[format=annotation] annotations that switch features on and off in response to SpEL expressions, normally evaluated with placeholders resolved from the javadoc:org.springframework.core.env.Environment[].
[[howto.application.customize-the-environment-or-application-context]]
== Customize the Environment or ApplicationContext Before It Starts
-A `SpringApplication` has `ApplicationListener` and `ApplicationContextInitializer` implementations that are used to apply customizations to the context or environment.
+A javadoc:org.springframework.boot.SpringApplication[] has javadoc:org.springframework.context.ApplicationListener[] and javadoc:org.springframework.context.ApplicationContextInitializer[] implementations that are used to apply customizations to the context or environment.
Spring Boot loads a number of such customizations for use internally from `META-INF/spring.factories`.
There is more than one way to register additional customizations:
-* Programmatically, per application, by calling the `addListeners` and `addInitializers` methods on `SpringApplication` before you run it.
+* Programmatically, per application, by calling the `addListeners` and `addInitializers` methods on javadoc:org.springframework.boot.SpringApplication[] before you run it.
* Declaratively, for all applications, by adding a `META-INF/spring.factories` and packaging a jar file that the applications all use as a library.
-The `SpringApplication` sends some special `ApplicationEvents` to the listeners (some even before the context is created) and then registers the listeners for events published by the `ApplicationContext` as well.
+The javadoc:org.springframework.boot.SpringApplication[] sends some special javadoc:org.springframework.test.context.event.ApplicationEvents[] to the listeners (some even before the context is created) and then registers the listeners for events published by the javadoc:org.springframework.context.ApplicationContext[] as well.
See xref:reference:features/spring-application.adoc#features.spring-application.application-events-and-listeners[] in the "`Spring Boot Features`" section for a complete list.
-It is also possible to customize the `Environment` before the application context is refreshed by using `EnvironmentPostProcessor`.
+It is also possible to customize the javadoc:org.springframework.core.env.Environment[] before the application context is refreshed by using javadoc:org.springframework.boot.env.EnvironmentPostProcessor[].
Each implementation should be registered in `META-INF/spring.factories`, as shown in the following example:
[source]
@@ -78,18 +78,18 @@ Each implementation should be registered in `META-INF/spring.factories`, as show
org.springframework.boot.env.EnvironmentPostProcessor=com.example.YourEnvironmentPostProcessor
----
-The implementation can load arbitrary files and add them to the `Environment`.
+The implementation can load arbitrary files and add them to the javadoc:org.springframework.core.env.Environment[].
For instance, the following example loads a YAML configuration file from the classpath:
include-code::MyEnvironmentPostProcessor[]
-TIP: The `Environment` has already been prepared with all the usual property sources that Spring Boot loads by default.
+TIP: The javadoc:org.springframework.core.env.Environment[] has already been prepared with all the usual property sources that Spring Boot loads by default.
It is therefore possible to get the location of the file from the environment.
The preceding example adds the `custom-resource` property source at the end of the list so that a key defined in any of the usual other locations takes precedence.
A custom implementation may define another order.
-CAUTION: While using `@PropertySource` on your `@SpringBootApplication` may seem to be a convenient way to load a custom resource in the `Environment`, we do not recommend it.
-Such property sources are not added to the `Environment` until the application context is being refreshed.
+CAUTION: While using javadoc:org.springframework.context.annotation.PropertySource[format=annotation] on your javadoc:org.springframework.boot.autoconfigure.SpringBootApplication[format=annotation] may seem to be a convenient way to load a custom resource in the javadoc:org.springframework.core.env.Environment[], we do not recommend it.
+Such property sources are not added to the javadoc:org.springframework.core.env.Environment[] until the application context is being refreshed.
This is too late to configure certain properties such as `+logging.*+` and `+spring.main.*+` which are read before refresh begins.
@@ -97,7 +97,7 @@ This is too late to configure certain properties such as `+logging.*+` and `+spr
[[howto.application.context-hierarchy]]
== Build an ApplicationContext Hierarchy (Adding a Parent or Root Context)
-You can use the `SpringApplicationBuilder` class to create parent/child `ApplicationContext` hierarchies.
+You can use the javadoc:org.springframework.boot.builder.SpringApplicationBuilder[] class to create parent/child javadoc:org.springframework.context.ApplicationContext[] hierarchies.
See xref:reference:features/spring-application.adoc#features.spring-application.fluent-builder-api[] in the "`Spring Boot Features`" section for more information.
@@ -106,8 +106,8 @@ See xref:reference:features/spring-application.adoc#features.spring-application.
== Create a Non-web Application
Not all Spring applications have to be web applications (or web services).
-If you want to execute some code in a `main` method but also bootstrap a Spring application to set up the infrastructure to use, you can use the `SpringApplication` features of Spring Boot.
-A `SpringApplication` changes its `ApplicationContext` class, depending on whether it thinks it needs a web application or not.
+If you want to execute some code in a `main` method but also bootstrap a Spring application to set up the infrastructure to use, you can use the javadoc:org.springframework.boot.SpringApplication[] features of Spring Boot.
+A javadoc:org.springframework.boot.SpringApplication[] changes its javadoc:org.springframework.context.ApplicationContext[] class, depending on whether it thinks it needs a web application or not.
The first thing you can do to help it is to leave server-related dependencies (such as the servlet API) off the classpath.
-If you cannot do that (for example, if you run two applications from the same code base) then you can explicitly call `setWebApplicationType(WebApplicationType.NONE)` on your `SpringApplication` instance or set the `applicationContextClass` property (through the Java API or with external properties).
-Application code that you want to run as your business logic can be implemented as a `CommandLineRunner` and dropped into the context as a `@Bean` definition.
+If you cannot do that (for example, if you run two applications from the same code base) then you can explicitly call `setWebApplicationType(WebApplicationType.NONE)` on your javadoc:org.springframework.boot.SpringApplication[] instance or set the `applicationContextClass` property (through the Java API or with external properties).
+Application code that you want to run as your business logic can be implemented as a javadoc:org.springframework.boot.CommandLineRunner[] and dropped into the context as a javadoc:org.springframework.context.annotation.Bean[format=annotation] definition.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/batch.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/batch.adoc
index 202f11a2c2..79a481165a 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/batch.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/batch.adoc
@@ -9,11 +9,11 @@ This section addresses those questions.
[[howto.batch.specifying-a-data-source]]
== Specifying a Batch Data Source
-By default, batch applications require a `DataSource` to store job details.
-Spring Batch expects a single `DataSource` by default.
-To have it use a `DataSource` other than the application’s main `DataSource`, declare a `DataSource` bean, annotating its `@Bean` method with `@BatchDataSource`.
-If you do so and want two data sources, remember to mark the other one `@Primary`.
-To take greater control, add `@EnableBatchProcessing` to one of your `@Configuration` classes or extend `DefaultBatchConfiguration`.
+By default, batch applications require a javadoc:javax.sql.DataSource[] to store job details.
+Spring Batch expects a single javadoc:javax.sql.DataSource[] by default.
+To have it use a javadoc:javax.sql.DataSource[] other than the application’s main javadoc:javax.sql.DataSource[], declare a javadoc:javax.sql.DataSource[] bean, annotating its javadoc:org.springframework.context.annotation.Bean[format=annotation] method with javadoc:org.springframework.boot.autoconfigure.batch.BatchDataSource[format=annotation].
+If you do so and want two data sources, remember to mark the other one javadoc:org.springframework.context.annotation.Primary[format=annotation].
+To take greater control, add javadoc:org.springframework.batch.core.configuration.annotation.EnableBatchProcessing[format=annotation] to one of your javadoc:org.springframework.context.annotation.Configuration[format=annotation] classes or extend javadoc:org.springframework.batch.core.configuration.support.DefaultBatchConfiguration[].
See the API documentation of javadoc:{url-spring-batch-javadoc}/org.springframework.batch.core.configuration.annotation.EnableBatchProcessing[format=annotation]
and javadoc:{url-spring-batch-javadoc}/org.springframework.batch.core.configuration.support.DefaultBatchConfiguration[] for more details.
@@ -24,8 +24,8 @@ For more info about Spring Batch, see the {url-spring-batch-site}[Spring Batch p
[[howto.batch.specifying-a-transaction-manager]]
== Specifying a Batch Transaction Manager
-Similar to xref:batch.adoc#howto.batch.specifying-a-data-source[], you can define a `PlatformTransactionManager` for use in the batch processing by marking it as `@BatchTransactionManager`.
-If you do so and want two transaction managers, remember to mark the other one as `@Primary`.
+Similar to xref:batch.adoc#howto.batch.specifying-a-data-source[], you can define a javadoc:org.springframework.transaction.PlatformTransactionManager[] for use in the batch processing by marking it as javadoc:org.springframework.boot.autoconfigure.batch.BatchTransactionManager[format=annotation].
+If you do so and want two transaction managers, remember to mark the other one as javadoc:org.springframework.context.annotation.Primary[format=annotation].
@@ -34,10 +34,10 @@ If you do so and want two transaction managers, remember to mark the other one a
Spring Batch auto-configuration is enabled by adding `spring-boot-starter-batch` to your application's classpath.
-If a single `Job` bean is found in the application context, it is executed on startup (see javadoc:org.springframework.boot.autoconfigure.batch.JobLauncherApplicationRunner[] for details).
-If multiple `Job` beans are found, the job that should be executed must be specified using configprop:spring.batch.job.name[].
+If a single javadoc:org.springframework.batch.core.Job[] bean is found in the application context, it is executed on startup (see javadoc:org.springframework.boot.autoconfigure.batch.JobLauncherApplicationRunner[] for details).
+If multiple javadoc:org.springframework.batch.core.Job[] beans are found, the job that should be executed must be specified using configprop:spring.batch.job.name[].
-To disable running a `Job` found in the application context, set the configprop:spring.batch.job.enabled[] to `false`.
+To disable running a javadoc:org.springframework.batch.core.Job[] found in the application context, set the configprop:spring.batch.job.enabled[] to `false`.
See {code-spring-boot-autoconfigure-src}/batch/BatchAutoConfiguration.java[`BatchAutoConfiguration`] for more details.
@@ -46,7 +46,7 @@ See {code-spring-boot-autoconfigure-src}/batch/BatchAutoConfiguration.java[`Batc
[[howto.batch.running-from-the-command-line]]
== Running From the Command Line
-Spring Boot converts any command line argument starting with `--` to a property to add to the `Environment`, see xref:reference:features/external-config.adoc#features.external-config.command-line-args[accessing command line properties].
+Spring Boot converts any command line argument starting with `--` to a property to add to the javadoc:org.springframework.core.env.Environment[], see xref:reference:features/external-config.adoc#features.external-config.command-line-args[accessing command line properties].
This should not be used to pass arguments to batch jobs.
To specify batch arguments on the command line, use the regular format (that is without `--`), as shown in the following example:
@@ -55,7 +55,7 @@ To specify batch arguments on the command line, use the regular format (that is
$ java -jar myapp.jar someParameter=someValue anotherParameter=anotherValue
----
-If you specify a property of the `Environment` on the command line, it is ignored by the job.
+If you specify a property of the javadoc:org.springframework.core.env.Environment[] on the command line, it is ignored by the job.
Consider the following command:
[source,shell]
@@ -70,17 +70,17 @@ This provides only one argument to the batch job: `someParameter=someValue`.
[[howto.batch.restarting-a-failed-job]]
== Restarting a Stopped or Failed Job
-To restart a failed `Job`, all parameters (identifying and non-identifying) must be re-specified on the command line.
+To restart a failed javadoc:org.springframework.batch.core.Job[], all parameters (identifying and non-identifying) must be re-specified on the command line.
Non-identifying parameters are *not* copied from the previous execution.
This allows them to be modified or removed.
-NOTE: When you're using a custom `JobParametersIncrementer`, you have to gather all parameters managed by the incrementer to restart a failed execution.
+NOTE: When you're using a custom javadoc:org.springframework.batch.core.JobParametersIncrementer[], you have to gather all parameters managed by the incrementer to restart a failed execution.
[[howto.batch.storing-job-repository]]
== Storing the Job Repository
-Spring Batch requires a data store for the `Job` repository.
+Spring Batch requires a data store for the javadoc:org.springframework.batch.core.Job[] repository.
If you use Spring Boot, you must use an actual database.
Note that it can be an in-memory database, see {url-spring-batch-docs}/job.html#configuringJobRepository[Configuring a Job Repository].
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/build.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/build.adoc
index a1f69de538..4ad61bd3a6 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/build.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/build.adoc
@@ -11,7 +11,7 @@ This section answers common questions about these plugins.
Both the Maven plugin and the Gradle plugin allow generating build information containing the coordinates, name, and version of the project.
The plugins can also be configured to add additional properties through configuration.
-When such a file is present, Spring Boot auto-configures a `BuildProperties` bean.
+When such a file is present, Spring Boot auto-configures a javadoc:org.springframework.boot.info.BuildProperties[] bean.
To generate build information with Maven, add an execution for the `build-info` goal, as shown in the following example:
@@ -83,7 +83,7 @@ Both the Maven and Gradle plugins allow the properties that are included in `git
TIP: The commit time in `git.properties` is expected to match the following format: `yyyy-MM-dd'T'HH:mm:ssZ`.
This is the default format for both plugins listed above.
-Using this format lets the time be parsed into a `Date` and its format, when serialized to JSON, to be controlled by Jackson's date serialization configuration settings.
+Using this format lets the time be parsed into a javadoc:java.util.Date[] and its format, when serialized to JSON, to be controlled by Jackson's date serialization configuration settings.
@@ -309,7 +309,7 @@ To make it executable, you can either use the `spring-boot-antlib` module or you
. Add the `provided` (embedded container) dependencies in a nested `BOOT-INF/lib` directory for a jar or `WEB-INF/lib-provided` for a war.
Remember *not* to compress the entries in the archive.
. Add the `spring-boot-loader` classes at the root of the archive (so that the `Main-Class` is available).
-. Use the appropriate launcher (such as `JarLauncher` for a jar file) as a `Main-Class` attribute in the manifest and specify the other properties it needs as manifest entries -- principally, by setting a `Start-Class` property.
+. Use the appropriate launcher (such as javadoc:org.springframework.boot.loader.launch.JarLauncher[] for a jar file) as a `Main-Class` attribute in the manifest and specify the other properties it needs as manifest entries -- principally, by setting a `Start-Class` property.
The following example shows how to build an executable archive with Ant:
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/data-access.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/data-access.adoc
index c842873a1e..b2928342e9 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/data-access.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/data-access.adoc
@@ -9,9 +9,9 @@ This section answers questions related to doing so.
[[howto.data-access.configure-custom-datasource]]
== Configure a Custom DataSource
-To configure your own `DataSource`, define a `@Bean` of that type in your configuration.
-Spring Boot reuses your `DataSource` anywhere one is required, including database initialization.
-If you need to externalize some settings, you can bind your `DataSource` to the environment (see xref:reference:features/external-config.adoc#features.external-config.typesafe-configuration-properties.third-party-configuration[]).
+To configure your own javadoc:javax.sql.DataSource[], define a javadoc:org.springframework.context.annotation.Bean[format=annotation] of that type in your configuration.
+Spring Boot reuses your javadoc:javax.sql.DataSource[] anywhere one is required, including database initialization.
+If you need to externalize some settings, you can bind your javadoc:javax.sql.DataSource[] to the environment (see xref:reference:features/external-config.adoc#features.external-config.typesafe-configuration-properties.third-party-configuration[]).
The following example shows how to define a data source in a bean:
@@ -28,17 +28,17 @@ app:
pool-size: 30
----
-Assuming that `SomeDataSource` has regular JavaBean properties for the URL, the username, and the pool size, these settings are bound automatically before the `DataSource` is made available to other components.
+Assuming that `SomeDataSource` has regular JavaBean properties for the URL, the username, and the pool size, these settings are bound automatically before the javadoc:javax.sql.DataSource[] is made available to other components.
-Spring Boot also provides a utility builder class, called `DataSourceBuilder`, that can be used to create one of the standard data sources (if it is on the classpath).
+Spring Boot also provides a utility builder class, called javadoc:org.springframework.boot.jdbc.DataSourceBuilder[], that can be used to create one of the standard data sources (if it is on the classpath).
The builder can detect which one to use based on what is available on the classpath.
It also auto-detects the driver based on the JDBC URL.
-The following example shows how to create a data source by using a `DataSourceBuilder`:
+The following example shows how to create a data source by using a javadoc:org.springframework.boot.jdbc.DataSourceBuilder[]:
include-code::builder/MyDataSourceConfiguration[]
-To run an app with that `DataSource`, all you need is the connection information.
+To run an app with that javadoc:javax.sql.DataSource[], all you need is the connection information.
Pool-specific settings can also be provided.
Check the implementation that is going to be used at runtime for more details.
@@ -54,10 +54,10 @@ app:
pool-size: 30
----
-However, there is a catch due to the method's `DataSource` return type.
-This hides the actual type of the connection pool so no configuration property metadata is generated for your custom `DataSource` and no auto-completion is available in your IDE.
-To address this problem, use the builder's `type(Class)` method to specify the type of `DataSource` to be built and update the method's return type.
-For example, the following shows how to create a `HikariDataSource` with `DataSourceBuilder`:
+However, there is a catch due to the method's javadoc:javax.sql.DataSource[] return type.
+This hides the actual type of the connection pool so no configuration property metadata is generated for your custom javadoc:javax.sql.DataSource[] and no auto-completion is available in your IDE.
+To address this problem, use the builder's `type(Class)` method to specify the type of javadoc:javax.sql.DataSource[] to be built and update the method's return type.
+For example, the following shows how to create a javadoc:com.zaxxer.hikari.HikariDataSource[] with javadoc:org.springframework.boot.jdbc.DataSourceBuilder[]:
include-code::simple/MyDataSourceConfiguration[]
@@ -74,15 +74,15 @@ app:
pool-size: 30
----
-To address this problem, make use of `DataSourceProperties` which will handle the `url` to `jdbc-url` translation for you.
-You can initialize a `DataSourceBuilder` from the state of any `DataSourceProperties` object using its `initializeDataSourceBuilder()` method.
-You could inject the `DataSourceProperties` that Spring Boot creates automatically, however, that would split your configuration across `+spring.datasource.*+` and `+app.datasource.*+`.
-To avoid this, define a custom `DataSourceProperties` with a custom configuration properties prefix, as shown in the following example:
+To address this problem, make use of javadoc:org.springframework.boot.autoconfigure.jdbc.DataSourceProperties[] which will handle the `url` to `jdbc-url` translation for you.
+You can initialize a javadoc:org.springframework.boot.jdbc.DataSourceBuilder[] from the state of any javadoc:org.springframework.boot.autoconfigure.jdbc.DataSourceProperties[] object using its `initializeDataSourceBuilder()` method.
+You could inject the javadoc:org.springframework.boot.autoconfigure.jdbc.DataSourceProperties[] that Spring Boot creates automatically, however, that would split your configuration across `+spring.datasource.*+` and `+app.datasource.*+`.
+To avoid this, define a custom javadoc:org.springframework.boot.autoconfigure.jdbc.DataSourceProperties[] with a custom configuration properties prefix, as shown in the following example:
include-code::configurable/MyDataSourceConfiguration[]
This setup is equivalent to what Spring Boot does for you by default, except that the pool's type is specified in code and its settings are exposed as `app.datasource.configuration.*` properties.
-`DataSourceProperties` takes care of the `url` to `jdbc-url` translation, so you can configure it as follows:
+javadoc:org.springframework.boot.autoconfigure.jdbc.DataSourceProperties[] takes care of the `url` to `jdbc-url` translation, so you can configure it as follows:
[configprops%novalidate,yaml]
----
@@ -97,8 +97,8 @@ app:
Note that, as the custom configuration specifies in code that Hikari should be used, `app.datasource.type` will have no effect.
-As described in xref:reference:data/sql.adoc#data.sql.datasource.connection-pool[], `DataSourceBuilder` supports several different connection pools.
-To use a pool other than Hikari, add it to the classpath, use the `type(Class)` method to specify the pool class to use, and update the `@Bean` method's return type to match.
+As described in xref:reference:data/sql.adoc#data.sql.datasource.connection-pool[], javadoc:org.springframework.boot.jdbc.DataSourceBuilder[] supports several different connection pools.
+To use a pool other than Hikari, add it to the classpath, use the `type(Class)` method to specify the pool class to use, and update the javadoc:org.springframework.context.annotation.Bean[format=annotation] method's return type to match.
This will also provide you with configuration property metadata for the specific connection pool that you've chosen.
TIP: Spring Boot will expose Hikari-specific settings to `spring.datasource.hikari`.
@@ -112,14 +112,14 @@ See xref:reference:data/sql.adoc#data.sql.datasource[] and the {code-spring-boot
== Configure Two DataSources
If you need to configure multiple data sources, you can apply the same tricks that were described in the previous section.
-You must, however, mark one of the `DataSource` instances as `@Primary`, because various auto-configurations down the road expect to be able to get one by type.
+You must, however, mark one of the javadoc:javax.sql.DataSource[] instances as javadoc:org.springframework.context.annotation.Primary[format=annotation], because various auto-configurations down the road expect to be able to get one by type.
-If you create your own `DataSource`, the auto-configuration backs off.
+If you create your own javadoc:javax.sql.DataSource[], the auto-configuration backs off.
In the following example, we provide the _exact_ same feature set as the auto-configuration provides on the primary data source:
include-code::MyDataSourcesConfiguration[]
-TIP: `firstDataSourceProperties` has to be flagged as `@Primary` so that the database initializer feature uses your copy (if you use the initializer).
+TIP: `firstDataSourceProperties` has to be flagged as javadoc:org.springframework.context.annotation.Primary[format=annotation] so that the database initializer feature uses your copy (if you use the initializer).
Both data sources are also bound for advanced customizations.
For instance, you could configure them as follows:
@@ -142,14 +142,14 @@ app:
max-total: 30
----
-You can apply the same concept to the secondary `DataSource` as well, as shown in the following example:
+You can apply the same concept to the secondary javadoc:javax.sql.DataSource[] as well, as shown in the following example:
include-code::MyCompleteDataSourcesConfiguration[]
The preceding example configures two data sources on custom configuration property namespaces with the same logic as Spring Boot would use in auto-configuration.
Note that each `configuration` sub namespace provides advanced settings based on the chosen implementation.
-As with xref:how-to:data-access.adoc#howto.data-access.configure-custom-datasource[configuring a single custom `DataSource`], the type of one or both of the `DataSource` beans can be customized using the `type(Class)` method on `DataSourceBuilder`.
+As with xref:how-to:data-access.adoc#howto.data-access.configure-custom-datasource[configuring a single custom javadoc:javax.sql.DataSource[]], the type of one or both of the javadoc:javax.sql.DataSource[] beans can be customized using the `type(Class)` method on javadoc:org.springframework.boot.jdbc.DataSourceBuilder[].
See xref:reference:data/sql.adoc#data.sql.datasource.connection-pool[] for details of the supported types.
@@ -157,14 +157,14 @@ See xref:reference:data/sql.adoc#data.sql.datasource.connection-pool[] for detai
[[howto.data-access.spring-data-repositories]]
== Use Spring Data Repositories
-Spring Data can create implementations of `Repository` interfaces of various flavors.
-Spring Boot handles all of that for you, as long as those `Repository` implementations are included in one of the xref:reference:using/auto-configuration.adoc#using.auto-configuration.packages[auto-configuration packages], typically the package (or a sub-package) of your main application class that is annotated with `@SpringBootApplication` or `@EnableAutoConfiguration`.
+Spring Data can create implementations of javadoc:org.springframework.data.repository.Repository[] interfaces of various flavors.
+Spring Boot handles all of that for you, as long as those javadoc:org.springframework.data.repository.Repository[] implementations are included in one of the xref:reference:using/auto-configuration.adoc#using.auto-configuration.packages[auto-configuration packages], typically the package (or a sub-package) of your main application class that is annotated with javadoc:org.springframework.boot.autoconfigure.SpringBootApplication[format=annotation] or javadoc:org.springframework.boot.autoconfigure.EnableAutoConfiguration[format=annotation].
For many applications, all you need is to put the right Spring Data dependencies on your classpath.
There is a `spring-boot-starter-data-jpa` for JPA, `spring-boot-starter-data-mongodb` for Mongodb, and various other starters for supported technologies.
-To get started, create some repository interfaces to handle your `@Entity` objects.
+To get started, create some repository interfaces to handle your javadoc:jakarta.persistence.Entity[format=annotation] objects.
-Spring Boot determines the location of your `Repository` implementations by scanning the xref:reference:using/auto-configuration.adoc#using.auto-configuration.packages[auto-configuration packages].
+Spring Boot determines the location of your javadoc:org.springframework.data.repository.Repository[] implementations by scanning the xref:reference:using/auto-configuration.adoc#using.auto-configuration.packages[auto-configuration packages].
For more control, use the `@Enable…Repositories` annotations from Spring Data.
For more about Spring Data, see the {url-spring-data-site}[Spring Data project page].
@@ -174,8 +174,8 @@ For more about Spring Data, see the {url-spring-data-site}[Spring Data project p
[[howto.data-access.separate-entity-definitions-from-spring-configuration]]
== Separate @Entity Definitions from Spring Configuration
-Spring Boot determines the location of your `@Entity` definitions by scanning the xref:reference:using/auto-configuration.adoc#using.auto-configuration.packages[auto-configuration packages].
-For more control, use the `@EntityScan` annotation, as shown in the following example:
+Spring Boot determines the location of your javadoc:jakarta.persistence.Entity[format=annotation] definitions by scanning the xref:reference:using/auto-configuration.adoc#using.auto-configuration.packages[auto-configuration packages].
+For more control, use the javadoc:org.springframework.boot.autoconfigure.domain.EntityScan[format=annotation] annotation, as shown in the following example:
include-code::MyApplication[]
@@ -184,7 +184,7 @@ include-code::MyApplication[]
[[howto.data-access.filter-scanned-entity-definitions]]
== Filter Scanned @Entity Definitions
-It is possible to filter the `@Entity` definitions using a `ManagedClassNameFilter` bean.
+It is possible to filter the javadoc:jakarta.persistence.Entity[format=annotation] definitions using a javadoc:org.springframework.orm.jpa.persistenceunit.ManagedClassNameFilter[] bean.
This can be useful in tests when only a sub-set of the available entities should be considered.
In the following example, only entities from the `com.example.app.customer` package are included:
@@ -199,7 +199,7 @@ Spring Data JPA already provides some vendor-independent configuration options (
Some of them are automatically detected according to the context so you should not have to set them.
The `spring.jpa.hibernate.ddl-auto` is a special case, because, depending on runtime conditions, it has different defaults.
-If an embedded database is used and no schema manager (such as Liquibase or Flyway) is handling the `DataSource`, it defaults to `create-drop`.
+If an embedded database is used and no schema manager (such as Liquibase or Flyway) is handling the javadoc:javax.sql.DataSource[], it defaults to `create-drop`.
In all other cases, it defaults to `none`.
The dialect to use is detected by the JPA provider.
@@ -217,7 +217,7 @@ spring:
show-sql: true
----
-In addition, all properties in `+spring.jpa.properties.*+` are passed through as normal JPA properties (with the prefix stripped) when the local `EntityManagerFactory` is created.
+In addition, all properties in `+spring.jpa.properties.*+` are passed through as normal JPA properties (with the prefix stripped) when the local javadoc:jakarta.persistence.EntityManagerFactory[] is created.
[WARNING]
====
@@ -228,7 +228,7 @@ For example, if you want to configure Hibernate's batch size you must use `+spri
If you use other forms, such as `batchSize` or `batch-size`, Hibernate will not apply the setting.
====
-TIP: If you need to apply advanced customization to Hibernate properties, consider registering a `HibernatePropertiesCustomizer` bean that will be invoked prior to creating the `EntityManagerFactory`.
+TIP: If you need to apply advanced customization to Hibernate properties, consider registering a javadoc:org.springframework.boot.autoconfigure.orm.jpa.HibernatePropertiesCustomizer[] bean that will be invoked prior to creating the javadoc:jakarta.persistence.EntityManagerFactory[].
This takes precedence over anything that is applied by the auto-configuration.
@@ -238,13 +238,13 @@ This takes precedence over anything that is applied by the auto-configuration.
Hibernate uses {url-hibernate-userguide}#naming[two different naming strategies] to map names from the object model to the corresponding database names.
The fully qualified class name of the physical and the implicit strategy implementations can be configured by setting the `spring.jpa.hibernate.naming.physical-strategy` and `spring.jpa.hibernate.naming.implicit-strategy` properties, respectively.
-Alternatively, if `ImplicitNamingStrategy` or `PhysicalNamingStrategy` beans are available in the application context, Hibernate will be automatically configured to use them.
+Alternatively, if javadoc:org.hibernate.boot.model.naming.ImplicitNamingStrategy[] or javadoc:org.hibernate.boot.model.naming.PhysicalNamingStrategy[] beans are available in the application context, Hibernate will be automatically configured to use them.
-By default, Spring Boot configures the physical naming strategy with `CamelCaseToUnderscoresNamingStrategy`.
+By default, Spring Boot configures the physical naming strategy with javadoc:org.hibernate.boot.model.naming.CamelCaseToUnderscoresNamingStrategy[].
Using this strategy, all dots are replaced by underscores and camel casing is replaced by underscores as well.
Additionally, by default, all table names are generated in lower case.
For example, a `TelephoneNumber` entity is mapped to the `telephone_number` table.
-If your schema requires mixed-case identifiers, define a custom `CamelCaseToUnderscoresNamingStrategy` bean, as shown in the following example:
+If your schema requires mixed-case identifiers, define a custom javadoc:org.hibernate.boot.model.naming.CamelCaseToUnderscoresNamingStrategy[] bean, as shown in the following example:
include-code::spring/MyHibernateConfiguration[]
@@ -274,12 +274,12 @@ Hibernate {url-hibernate-userguide}#caching[second-level cache] can be configure
Rather than configuring Hibernate to lookup the cache provider again, it is better to provide the one that is available in the context whenever possible.
To do this with JCache, first make sure that `org.hibernate.orm:hibernate-jcache` is available on the classpath.
-Then, add a `HibernatePropertiesCustomizer` bean as shown in the following example:
+Then, add a javadoc:org.springframework.boot.autoconfigure.orm.jpa.HibernatePropertiesCustomizer[] bean as shown in the following example:
include-code::MyHibernateSecondLevelCacheConfiguration[]
-This customizer will configure Hibernate to use the same `CacheManager` as the one that the application uses.
-It is also possible to use separate `CacheManager` instances.
+This customizer will configure Hibernate to use the same javadoc:org.springframework.cache.CacheManager[] as the one that the application uses.
+It is also possible to use separate javadoc:org.springframework.cache.CacheManager[] instances.
For details, see {url-hibernate-userguide}#caching-provider-jcache[the Hibernate user guide].
@@ -287,16 +287,16 @@ For details, see {url-hibernate-userguide}#caching-provider-jcache[the Hibernate
[[howto.data-access.dependency-injection-in-hibernate-components]]
== Use Dependency Injection in Hibernate Components
-By default, Spring Boot registers a `BeanContainer` implementation that uses the `BeanFactory` so that converters and entity listeners can use regular dependency injection.
+By default, Spring Boot registers a javadoc:org.hibernate.resource.beans.container.spi.BeanContainer[] implementation that uses the javadoc:org.springframework.beans.factory.BeanFactory[] so that converters and entity listeners can use regular dependency injection.
-You can disable or tune this behavior by registering a `HibernatePropertiesCustomizer` that removes or changes the `hibernate.resource.beans.container` property.
+You can disable or tune this behavior by registering a javadoc:org.springframework.boot.autoconfigure.orm.jpa.HibernatePropertiesCustomizer[] that removes or changes the `hibernate.resource.beans.container` property.
[[howto.data-access.use-custom-entity-manager]]
== Use a Custom EntityManagerFactory
-To take full control of the configuration of the `EntityManagerFactory`, you need to add a `@Bean` named '`entityManagerFactory`'.
+To take full control of the configuration of the javadoc:jakarta.persistence.EntityManagerFactory[], you need to add a javadoc:org.springframework.context.annotation.Bean[format=annotation] named '`entityManagerFactory`'.
Spring Boot auto-configuration switches off its entity manager in the presence of a bean of that type.
@@ -304,25 +304,25 @@ Spring Boot auto-configuration switches off its entity manager in the presence o
[[howto.data-access.use-multiple-entity-managers]]
== Using Multiple EntityManagerFactories
-If you need to use JPA against multiple data sources, you likely need one `EntityManagerFactory` per data source.
-The `LocalContainerEntityManagerFactoryBean` from Spring ORM allows you to configure an `EntityManagerFactory` for your needs.
-You can also reuse `JpaProperties` to bind settings for each `EntityManagerFactory`, as shown in the following example:
+If you need to use JPA against multiple data sources, you likely need one javadoc:jakarta.persistence.EntityManagerFactory[] per data source.
+The javadoc:org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean[] from Spring ORM allows you to configure an javadoc:jakarta.persistence.EntityManagerFactory[] for your needs.
+You can also reuse javadoc:org.springframework.boot.autoconfigure.orm.jpa.JpaProperties[] to bind settings for each javadoc:jakarta.persistence.EntityManagerFactory[], as shown in the following example:
include-code::MyEntityManagerFactoryConfiguration[]
-The example above creates an `EntityManagerFactory` using a `DataSource` bean named `firstDataSource`.
+The example above creates an javadoc:jakarta.persistence.EntityManagerFactory[] using a javadoc:javax.sql.DataSource[] bean named `firstDataSource`.
It scans entities located in the same package as `Order`.
It is possible to map additional JPA properties using the `app.first.jpa` namespace.
-NOTE: When you create a bean for `LocalContainerEntityManagerFactoryBean` yourself, any customization that was applied during the creation of the auto-configured `LocalContainerEntityManagerFactoryBean` is lost.
-For example, in the case of Hibernate, any properties under the `spring.jpa.hibernate` prefix will not be automatically applied to your `LocalContainerEntityManagerFactoryBean`.
-If you were relying on these properties for configuring things like the naming strategy or the DDL mode, you will need to explicitly configure that when creating the `LocalContainerEntityManagerFactoryBean` bean.
+NOTE: When you create a bean for javadoc:org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean[] yourself, any customization that was applied during the creation of the auto-configured javadoc:org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean[] is lost.
+For example, in the case of Hibernate, any properties under the `spring.jpa.hibernate` prefix will not be automatically applied to your javadoc:org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean[].
+If you were relying on these properties for configuring things like the naming strategy or the DDL mode, you will need to explicitly configure that when creating the javadoc:org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean[] bean.
You should provide a similar configuration for any additional data sources for which you need JPA access.
-To complete the picture, you need to configure a `JpaTransactionManager` for each `EntityManagerFactory` as well.
+To complete the picture, you need to configure a javadoc:org.springframework.orm.jpa.JpaTransactionManager[] for each javadoc:jakarta.persistence.EntityManagerFactory[] as well.
Alternatively, you might be able to use a JTA transaction manager that spans both.
-If you use Spring Data, you need to configure `@EnableJpaRepositories` accordingly, as shown in the following examples:
+If you use Spring Data, you need to configure javadoc:org.springframework.data.jpa.repository.config.EnableJpaRepositories[format=annotation] accordingly, as shown in the following examples:
include-code::OrderConfiguration[]
@@ -334,7 +334,7 @@ include-code::CustomerConfiguration[]
== Use a Traditional persistence.xml File
Spring Boot will not search for or use a `META-INF/persistence.xml` by default.
-If you prefer to use a traditional `persistence.xml`, you need to define your own `@Bean` of type `LocalEntityManagerFactoryBean` (with an ID of '`entityManagerFactory`') and set the persistence unit name there.
+If you prefer to use a traditional `persistence.xml`, you need to define your own javadoc:org.springframework.context.annotation.Bean[format=annotation] of type javadoc:org.springframework.orm.jpa.LocalEntityManagerFactoryBean[] (with an ID of '`entityManagerFactory`') and set the persistence unit name there.
See {code-spring-boot-autoconfigure-src}/orm/jpa/JpaBaseConfiguration.java[`JpaBaseConfiguration`] for the default settings.
@@ -343,12 +343,12 @@ See {code-spring-boot-autoconfigure-src}/orm/jpa/JpaBaseConfiguration.java[`JpaB
[[howto.data-access.use-spring-data-jpa-and-mongo-repositories]]
== Use Spring Data JPA and Mongo Repositories
-Spring Data JPA and Spring Data Mongo can both automatically create `Repository` implementations for you.
+Spring Data JPA and Spring Data Mongo can both automatically create javadoc:org.springframework.data.repository.Repository[] implementations for you.
If they are both present on the classpath, you might have to do some extra configuration to tell Spring Boot which repositories to create.
-The most explicit way to do that is to use the standard Spring Data `@EnableJpaRepositories` and `@EnableMongoRepositories` annotations and provide the location of your `Repository` interfaces.
+The most explicit way to do that is to use the standard Spring Data javadoc:org.springframework.data.jpa.repository.config.EnableJpaRepositories[format=annotation] and javadoc:org.springframework.data.mongodb.repository.config.EnableMongoRepositories[format=annotation] annotations and provide the location of your javadoc:org.springframework.data.repository.Repository[] interfaces.
There are also flags (`+spring.data.*.repositories.enabled+` and `+spring.data.*.repositories.type+`) that you can use to switch the auto-configured repositories on and off in external configuration.
-Doing so is useful, for instance, in case you want to switch off the Mongo repositories and still use the auto-configured `MongoTemplate`.
+Doing so is useful, for instance, in case you want to switch off the Mongo repositories and still use the auto-configured javadoc:org.springframework.data.mongodb.core.MongoTemplate[].
The same obstacle and the same features exist for other auto-configured Spring Data repository types (Elasticsearch, Redis, and others).
To work with them, change the names of the annotations and flags accordingly.
@@ -367,13 +367,13 @@ Note that if you are using Spring Data REST, you must use the properties in the
[[howto.data-access.exposing-spring-data-repositories-as-rest]]
== Expose Spring Data Repositories as REST Endpoint
-Spring Data REST can expose the `Repository` implementations as REST endpoints for you,
+Spring Data REST can expose the javadoc:org.springframework.data.repository.Repository[] implementations as REST endpoints for you,
provided Spring MVC has been enabled for the application.
Spring Boot exposes a set of useful properties (from the `spring.data.rest` namespace) that customize the javadoc:{url-spring-data-rest-javadoc}/org.springframework.data.rest.core.config.RepositoryRestConfiguration[].
If you need to provide additional customization, you should use a javadoc:{url-spring-data-rest-javadoc}/org.springframework.data.rest.webmvc.config.RepositoryRestConfigurer[] bean.
-NOTE: If you do not specify any order on your custom `RepositoryRestConfigurer`, it runs after the one Spring Boot uses internally.
+NOTE: If you do not specify any order on your custom javadoc:org.springframework.data.rest.webmvc.config.RepositoryRestConfigurer[], it runs after the one Spring Boot uses internally.
If you need to specify an order, make sure it is higher than 0.
@@ -385,8 +385,8 @@ If you want to configure a component that JPA uses, then you need to ensure that
When the component is auto-configured, Spring Boot takes care of this for you.
For example, when Flyway is auto-configured, Hibernate is configured to depend on Flyway so that Flyway has a chance to initialize the database before Hibernate tries to use it.
-If you are configuring a component yourself, you can use an `EntityManagerFactoryDependsOnPostProcessor` subclass as a convenient way of setting up the necessary dependencies.
-For example, if you use Hibernate Search with Elasticsearch as its index manager, any `EntityManagerFactory` beans must be configured to depend on the `elasticsearchClient` bean, as shown in the following example:
+If you are configuring a component yourself, you can use an javadoc:org.springframework.boot.autoconfigure.orm.jpa.EntityManagerFactoryDependsOnPostProcessor[] subclass as a convenient way of setting up the necessary dependencies.
+For example, if you use Hibernate Search with Elasticsearch as its index manager, any javadoc:jakarta.persistence.EntityManagerFactory[] beans must be configured to depend on the `elasticsearchClient` bean, as shown in the following example:
include-code::ElasticsearchEntityManagerFactoryDependsOnPostProcessor[]
@@ -395,7 +395,7 @@ include-code::ElasticsearchEntityManagerFactoryDependsOnPostProcessor[]
[[howto.data-access.configure-jooq-with-multiple-datasources]]
== Configure jOOQ with Two DataSources
-If you need to use jOOQ with multiple data sources, you should create your own `DSLContext` for each one.
+If you need to use jOOQ with multiple data sources, you should create your own javadoc:org.jooq.DSLContext[] for each one.
See {code-spring-boot-autoconfigure-src}/jooq/JooqAutoConfiguration.java[`JooqAutoConfiguration`] for more details.
-TIP: In particular, `JooqExceptionTranslator` and `SpringTransactionProvider` can be reused to provide similar features to what the auto-configuration does with a single `DataSource`.
+TIP: In particular, javadoc:org.springframework.boot.autoconfigure.jooq.JooqExceptionTranslator[] and javadoc:org.springframework.boot.autoconfigure.jooq.SpringTransactionProvider[] can be reused to provide similar features to what the auto-configuration does with a single javadoc:javax.sql.DataSource[].
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/data-initialization.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/data-initialization.adoc
index e75fe60ed8..2eb191fc3f 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/data-initialization.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/data-initialization.adoc
@@ -13,7 +13,7 @@ It is recommended to use a single mechanism for schema generation.
You can set configprop:spring.jpa.hibernate.ddl-auto[] to control Hibernate's database initialization.
Supported values are `none`, `validate`, `update`, `create`, and `create-drop`.
Spring Boot chooses a default value for you based on whether you are using an embedded database.
-An embedded database is identified by looking at the `Connection` type and JDBC url.
+An embedded database is identified by looking at the javadoc:java.sql.Connection[] type and JDBC url.
`hsqldb`, `h2`, or `derby` are embedded databases and others are not.
If an embedded database is identified and no schema manager (Flyway or Liquibase) has been detected, `ddl-auto` defaults to `create-drop`.
In all other cases, it defaults to `none`.
@@ -33,7 +33,7 @@ It is a Hibernate feature (and has nothing to do with Spring).
[[howto.data-initialization.using-basic-sql-scripts]]
== Initialize a Database Using Basic SQL Scripts
-Spring Boot can automatically create the schema (DDL scripts) of your JDBC `DataSource` or R2DBC `ConnectionFactory` and initialize its data (DML scripts).
+Spring Boot can automatically create the schema (DDL scripts) of your JDBC javadoc:javax.sql.DataSource[] or R2DBC javadoc:io.r2dbc.spi.ConnectionFactory[] and initialize its data (DML scripts).
By default, it loads schema scripts from `optional:classpath*:schema.sql` and data scripts from `optional:classpath*:data.sql`.
The locations of these schema and data scripts can be customized using configprop:spring.sql.init.schema-locations[] and configprop:spring.sql.init.data-locations[] respectively.
@@ -51,10 +51,10 @@ By default, Spring Boot enables the fail-fast feature of its script-based databa
This means that, if the scripts cause exceptions, the application fails to start.
You can tune that behavior by setting configprop:spring.sql.init.continue-on-error[].
-Script-based `DataSource` initialization is performed, by default, before any JPA `EntityManagerFactory` beans are created.
+Script-based javadoc:javax.sql.DataSource[] initialization is performed, by default, before any JPA javadoc:jakarta.persistence.EntityManagerFactory[] beans are created.
`schema.sql` can be used to create the schema for JPA-managed entities and `data.sql` can be used to populate it.
-While we do not recommend using multiple data source initialization technologies, if you want script-based `DataSource` initialization to be able to build upon the schema creation performed by Hibernate, set configprop:spring.jpa.defer-datasource-initialization[] to `true`.
-This will defer data source initialization until after any `EntityManagerFactory` beans have been created and initialized.
+While we do not recommend using multiple data source initialization technologies, if you want script-based javadoc:javax.sql.DataSource[] initialization to be able to build upon the schema creation performed by Hibernate, set configprop:spring.jpa.defer-datasource-initialization[] to `true`.
+This will defer data source initialization until after any javadoc:jakarta.persistence.EntityManagerFactory[] beans have been created and initialized.
`schema.sql` can then be used to make additions to any schema creation performed by Hibernate and `data.sql` can be used to populate it.
NOTE: The initialization scripts support `--` for single line comments and `/++*++ ++*++/` for block comments.
@@ -129,25 +129,25 @@ Rather than using `db/migration`, the preceding configuration sets the directory
The list of supported databases is available in javadoc:org.springframework.boot.jdbc.DatabaseDriver[].
Migrations can also be written in Java.
-Flyway will be auto-configured with any beans that implement `JavaMigration`.
+Flyway will be auto-configured with any beans that implement javadoc:org.flywaydb.core.api.migration.JavaMigration[].
javadoc:org.springframework.boot.autoconfigure.flyway.FlywayProperties[] provides most of Flyway's settings and a small set of additional properties that can be used to disable the migrations or switch off the location checking.
-If you need more control over the configuration, consider registering a `FlywayConfigurationCustomizer` bean.
+If you need more control over the configuration, consider registering a javadoc:org.springframework.boot.autoconfigure.flyway.FlywayConfigurationCustomizer[] bean.
Spring Boot calls `Flyway.migrate()` to perform the database migration.
-If you would like more control, provide a `@Bean` that implements javadoc:org.springframework.boot.autoconfigure.flyway.FlywayMigrationStrategy[].
+If you would like more control, provide a javadoc:org.springframework.context.annotation.Bean[format=annotation] that implements javadoc:org.springframework.boot.autoconfigure.flyway.FlywayMigrationStrategy[].
Flyway supports SQL and Java https://documentation.red-gate.com/fd/callback-concept-184127466.html[callbacks].
To use SQL-based callbacks, place the callback scripts in the `classpath:db/migration` directory.
-To use Java-based callbacks, create one or more beans that implement `Callback`.
-Any such beans are automatically registered with `Flyway`.
-They can be ordered by using `@Order` or by implementing `Ordered`.
+To use Java-based callbacks, create one or more beans that implement javadoc:org.flywaydb.core.api.callback.Callback[].
+Any such beans are automatically registered with javadoc:org.flywaydb.core.Flyway[].
+They can be ordered by using javadoc:org.springframework.core.annotation.Order[format=annotation] or by implementing javadoc:org.springframework.core.Ordered[].
-By default, Flyway autowires the (`@Primary`) `DataSource` in your context and uses that for migrations.
-If you like to use a different `DataSource`, you can create one and mark its `@Bean` as `@FlywayDataSource`.
-If you do so and want two data sources, remember to create another one and mark it as `@Primary`.
-Alternatively, you can use Flyway's native `DataSource` by setting `spring.flyway.[url,user,password]` in external properties.
-Setting either `spring.flyway.url` or `spring.flyway.user` is sufficient to cause Flyway to use its own `DataSource`.
+By default, Flyway autowires the (`@Primary`) javadoc:javax.sql.DataSource[] in your context and uses that for migrations.
+If you like to use a different javadoc:javax.sql.DataSource[], you can create one and mark its javadoc:org.springframework.context.annotation.Bean[format=annotation] as javadoc:org.springframework.boot.autoconfigure.flyway.FlywayDataSource[format=annotation].
+If you do so and want two data sources, remember to create another one and mark it as javadoc:org.springframework.context.annotation.Primary[format=annotation].
+Alternatively, you can use Flyway's native javadoc:javax.sql.DataSource[] by setting `spring.flyway.[url,user,password]` in external properties.
+Setting either `spring.flyway.url` or `spring.flyway.user` is sufficient to cause Flyway to use its own javadoc:javax.sql.DataSource[].
If any of the three properties has not been set, the value of its equivalent `spring.datasource` property will be used.
You can also use Flyway to provide data for specific scenarios.
@@ -181,11 +181,11 @@ It is not possible to use two different ways to initialize the database (for exa
By default, the master change log is read from `db/changelog/db.changelog-master.yaml`, but you can change the location by setting `spring.liquibase.change-log`.
In addition to YAML, Liquibase also supports JSON, XML, and SQL change log formats.
-By default, Liquibase autowires the (`@Primary`) `DataSource` in your context and uses that for migrations.
-If you need to use a different `DataSource`, you can create one and mark its `@Bean` as `@LiquibaseDataSource`.
-If you do so and you want two data sources, remember to create another one and mark it as `@Primary`.
-Alternatively, you can use Liquibase's native `DataSource` by setting `spring.liquibase.[driver-class-name,url,user,password]` in external properties.
-Setting either `spring.liquibase.url` or `spring.liquibase.user` is sufficient to cause Liquibase to use its own `DataSource`.
+By default, Liquibase autowires the (`@Primary`) javadoc:javax.sql.DataSource[] in your context and uses that for migrations.
+If you need to use a different javadoc:javax.sql.DataSource[], you can create one and mark its javadoc:org.springframework.context.annotation.Bean[format=annotation] as javadoc:org.springframework.boot.autoconfigure.liquibase.LiquibaseDataSource[format=annotation].
+If you do so and you want two data sources, remember to create another one and mark it as javadoc:org.springframework.context.annotation.Primary[format=annotation].
+Alternatively, you can use Liquibase's native javadoc:javax.sql.DataSource[] by setting `spring.liquibase.[driver-class-name,url,user,password]` in external properties.
+Setting either `spring.liquibase.url` or `spring.liquibase.user` is sufficient to cause Liquibase to use its own javadoc:javax.sql.DataSource[].
If any of the three properties has not been set, the value of its equivalent `spring.datasource` property will be used.
See javadoc:org.springframework.boot.autoconfigure.liquibase.LiquibaseProperties[] for details about available settings such as contexts, the default schema, and others.
@@ -239,7 +239,7 @@ It includes the production changelog and then declares a new changeset, whose `r
You can now use for example the https://docs.liquibase.com/change-types/insert.html[insert changeset] to insert data or the https://docs.liquibase.com/change-types/sql.html[sql changeset] to execute SQL directly.
The last thing to do is to configure Spring Boot to activate the `test` profile when running tests.
-To do this, you can add the `@ActiveProfiles("test")` annotation to your `@SpringBootTest` annotated test classes.
+To do this, you can add the `@ActiveProfiles("test")` annotation to your javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation] annotated test classes.
@@ -258,15 +258,15 @@ If, during startup, your application tries to access the database and it has not
Spring Boot will automatically detect beans of the following types that initialize an SQL database:
-- `DataSourceScriptDatabaseInitializer`
-- `EntityManagerFactory`
-- `Flyway`
-- `FlywayMigrationInitializer`
-- `R2dbcScriptDatabaseInitializer`
-- `SpringLiquibase`
+- javadoc:org.springframework.boot.jdbc.init.DataSourceScriptDatabaseInitializer[]
+- javadoc:jakarta.persistence.EntityManagerFactory[]
+- javadoc:org.flywaydb.core.Flyway[]
+- javadoc:org.springframework.boot.autoconfigure.flyway.FlywayMigrationInitializer[]
+- javadoc:org.springframework.boot.r2dbc.init.R2dbcScriptDatabaseInitializer[]
+- javadoc:liquibase.integration.spring.SpringLiquibase[]
If you are using a third-party starter for a database initialization library, it may provide a detector such that beans of other types are also detected automatically.
-To have other beans be detected, register an implementation of `DatabaseInitializerDetector` in `META-INF/spring.factories`.
+To have other beans be detected, register an implementation of javadoc:org.springframework.boot.sql.init.dependency.DatabaseInitializerDetector[] in `META-INF/spring.factories`.
@@ -275,13 +275,13 @@ To have other beans be detected, register an implementation of `DatabaseInitiali
Spring Boot will automatically detect beans of the following types that depends upon database initialization:
-- `AbstractEntityManagerFactoryBean` (unless configprop:spring.jpa.defer-datasource-initialization[] is set to `true`)
-- `DSLContext` (jOOQ)
-- `EntityManagerFactory` (unless configprop:spring.jpa.defer-datasource-initialization[] is set to `true`)
-- `JdbcClient`
-- `JdbcOperations`
-- `NamedParameterJdbcOperations`
+- javadoc:org.springframework.orm.jpa.AbstractEntityManagerFactoryBean[] (unless configprop:spring.jpa.defer-datasource-initialization[] is set to `true`)
+- javadoc:org.jooq.DSLContext[] (jOOQ)
+- javadoc:jakarta.persistence.EntityManagerFactory[] (unless configprop:spring.jpa.defer-datasource-initialization[] is set to `true`)
+- javadoc:org.springframework.jdbc.core.simple.JdbcClient[]
+- javadoc:org.springframework.jdbc.core.JdbcOperations[]
+- javadoc:org.springframework.jdbc.core.namedparam.NamedParameterJdbcOperations[]
If you are using a third-party starter data access library, it may provide a detector such that beans of other types are also detected automatically.
-To have other beans be detected, register an implementation of `DependsOnDatabaseInitializationDetector` in `META-INF/spring.factories`.
-Alternatively, annotate the bean's class or its `@Bean` method with `@DependsOnDatabaseInitialization`.
+To have other beans be detected, register an implementation of javadoc:org.springframework.boot.sql.init.dependency.DependsOnDatabaseInitializationDetector[] in `META-INF/spring.factories`.
+Alternatively, annotate the bean's class or its javadoc:org.springframework.context.annotation.Bean[format=annotation] method with javadoc:org.springframework.boot.sql.init.dependency.DependsOnDatabaseInitialization[format=annotation].
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/deployment/cloud.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/deployment/cloud.adoc
index bf0b0a12bf..9874a470bb 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/deployment/cloud.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/deployment/cloud.adoc
@@ -94,7 +94,7 @@ By default, metadata about the running application as well as service connection
This architecture decision is due to Cloud Foundry's polyglot (any language and platform can be supported as a buildpack) nature.
Process-scoped environment variables are language agnostic.
-Environment variables do not always make for the easiest API, so Spring Boot automatically extracts them and flattens the data into properties that can be accessed through Spring's `Environment` abstraction, as shown in the following example:
+Environment variables do not always make for the easiest API, so Spring Boot automatically extracts them and flattens the data into properties that can be accessed through Spring's javadoc:org.springframework.core.env.Environment[] abstraction, as shown in the following example:
include-code::MyBean[]
@@ -161,7 +161,7 @@ The following example shows the `Procfile` for our starter REST application:
web: java -Dserver.port=$PORT -jar target/demo-0.0.1-SNAPSHOT.jar
----
-Spring Boot makes `-D` arguments available as properties accessible from a Spring `Environment` instance.
+Spring Boot makes `-D` arguments available as properties accessible from a Spring javadoc:org.springframework.core.env.Environment[] instance.
The `server.port` configuration property is fed to the embedded Tomcat, Jetty, or Undertow instance, which then uses the port when it starts up.
The `$PORT` environment variable is assigned to us by the Heroku PaaS.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/deployment/traditional-deployment.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/deployment/traditional-deployment.adoc
index c25ae63488..5bb5888df5 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/deployment/traditional-deployment.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/deployment/traditional-deployment.adoc
@@ -11,9 +11,9 @@ This section answers common questions about traditional deployment.
WARNING: Because Spring WebFlux does not strictly depend on the servlet API and applications are deployed by default on an embedded Reactor Netty server, War deployment is not supported for WebFlux applications.
-The first step in producing a deployable war file is to provide a `SpringBootServletInitializer` subclass and override its `configure` method.
+The first step in producing a deployable war file is to provide a javadoc:org.springframework.boot.web.servlet.support.SpringBootServletInitializer[] subclass and override its `configure` method.
Doing so makes use of Spring Framework's servlet 3.0 support and lets you configure your application when it is launched by the servlet container.
-Typically, you should update your application's main class to extend `SpringBootServletInitializer`, as shown in the following example:
+Typically, you should update your application's main class to extend javadoc:org.springframework.boot.web.servlet.support.SpringBootServletInitializer[], as shown in the following example:
include-code::MyApplication[]
@@ -72,27 +72,27 @@ This means that, in addition to being deployable to a servlet container, you can
[[howto.traditional-deployment.convert-existing-application]]
== Convert an Existing Application to Spring Boot
-To convert an existing non-web Spring application to a Spring Boot application, replace the code that creates your `ApplicationContext` and replace it with calls to `SpringApplication` or `SpringApplicationBuilder`.
+To convert an existing non-web Spring application to a Spring Boot application, replace the code that creates your javadoc:org.springframework.context.ApplicationContext[] and replace it with calls to javadoc:org.springframework.boot.SpringApplication[] or javadoc:org.springframework.boot.builder.SpringApplicationBuilder[].
Spring MVC web applications are generally amenable to first creating a deployable war application and then migrating it later to an executable war or jar.
-To create a deployable war by extending `SpringBootServletInitializer` (for example, in a class called `Application`) and adding the Spring Boot `@SpringBootApplication` annotation, use code similar to that shown in the following example:
+To create a deployable war by extending javadoc:org.springframework.boot.web.servlet.support.SpringBootServletInitializer[] (for example, in a class called `Application`) and adding the Spring Boot javadoc:org.springframework.boot.autoconfigure.SpringBootApplication[format=annotation] annotation, use code similar to that shown in the following example:
include-code::MyApplication[tag=!main]
-Remember that, whatever you put in the `sources` is merely a Spring `ApplicationContext`.
+Remember that, whatever you put in the `sources` is merely a Spring javadoc:org.springframework.context.ApplicationContext[].
Normally, anything that already works should work here.
There might be some beans you can remove later and let Spring Boot provide its own defaults for them, but it should be possible to get something working before you need to do that.
Static resources can be moved to `/public` (or `/static` or `/resources` or `/META-INF/resources`) in the classpath root.
The same applies to `messages.properties` (which Spring Boot automatically detects in the root of the classpath).
-Vanilla usage of Spring `DispatcherServlet` and Spring Security should require no further changes.
+Vanilla usage of Spring javadoc:org.springframework.web.servlet.DispatcherServlet[] and Spring Security should require no further changes.
If you have other features in your application (for instance, using other servlets or filters), you may need to add some configuration to your `Application` context, by replacing those elements from the `web.xml`, as follows:
-* A `@Bean` of type `Servlet` or `ServletRegistrationBean` installs that bean in the container as if it were a `` and `` in `web.xml`.
-* A `@Bean` of type `Filter` or `FilterRegistrationBean` behaves similarly (as a `` and ``).
-* An `ApplicationContext` in an XML file can be added through an `@ImportResource` in your `Application`.
- Alternatively, cases where annotation configuration is heavily used already can be recreated in a few lines as `@Bean` definitions.
+* A javadoc:org.springframework.context.annotation.Bean[format=annotation] of type javadoc:jakarta.servlet.Servlet[] or javadoc:org.springframework.boot.web.servlet.ServletRegistrationBean[] installs that bean in the container as if it were a `` and `` in `web.xml`.
+* A javadoc:org.springframework.context.annotation.Bean[format=annotation] of type javadoc:jakarta.servlet.Filter[] or javadoc:org.springframework.boot.web.servlet.FilterRegistrationBean[] behaves similarly (as a `` and ``).
+* An javadoc:org.springframework.context.ApplicationContext[] in an XML file can be added through an javadoc:org.springframework.context.annotation.ImportResource[format=annotation] in your `+Application+`.
+ Alternatively, cases where annotation configuration is heavily used already can be recreated in a few lines as javadoc:org.springframework.context.annotation.Bean[format=annotation] definitions.
Once the war file is working, you can make it executable by adding a `main` method to your `Application`, as shown in the following example:
@@ -100,7 +100,7 @@ include-code::MyApplication[tag=main]
[NOTE]
====
-If you intend to start your application as a war or as an executable application, you need to share the customizations of the builder in a method that is both available to the `SpringBootServletInitializer` callback and in the `main` method in a class similar to the following:
+If you intend to start your application as a war or as an executable application, you need to share the customizations of the builder in a method that is both available to the javadoc:org.springframework.boot.web.servlet.support.SpringBootServletInitializer[] callback and in the `main` method in a class similar to the following:
include-code::both/MyApplication[]
====
@@ -115,11 +115,11 @@ Applications can fall into more than one category:
All of these should be amenable to translation, but each might require slightly different techniques.
Servlet 3.0+ applications might translate pretty easily if they already use the Spring Servlet 3.0+ initializer support classes.
-Normally, all the code from an existing `WebApplicationInitializer` can be moved into a `SpringBootServletInitializer`.
-If your existing application has more than one `ApplicationContext` (for example, if it uses `AbstractDispatcherServletInitializer`) then you might be able to combine all your context sources into a single `SpringApplication`.
+Normally, all the code from an existing javadoc:org.springframework.web.WebApplicationInitializer[] can be moved into a javadoc:org.springframework.boot.web.servlet.support.SpringBootServletInitializer[].
+If your existing application has more than one javadoc:org.springframework.context.ApplicationContext[] (for example, if it uses javadoc:org.springframework.web.servlet.support.AbstractDispatcherServletInitializer[]) then you might be able to combine all your context sources into a single javadoc:org.springframework.boot.SpringApplication[].
The main complication you might encounter is if combining does not work and you need to maintain the context hierarchy.
See the xref:application.adoc#howto.application.context-hierarchy[entry on building a hierarchy] for examples.
-An existing parent context that contains web-specific features usually needs to be broken up so that all the `ServletContextAware` components are in the child context.
+An existing parent context that contains web-specific features usually needs to be broken up so that all the javadoc:org.springframework.web.context.ServletContextAware[] components are in the child context.
Applications that are not already Spring applications might be convertible to Spring Boot applications, and the previously mentioned guidance may help.
However, you may yet encounter problems.
@@ -130,7 +130,7 @@ In that case, we suggest https://stackoverflow.com/questions/tagged/spring-boot[
[[howto.traditional-deployment.weblogic]]
== Deploying a WAR to WebLogic
-To deploy a Spring Boot application to WebLogic, you must ensure that your servlet initializer *directly* implements `WebApplicationInitializer` (even if you extend from a base class that already implements it).
+To deploy a Spring Boot application to WebLogic, you must ensure that your servlet initializer *directly* implements javadoc:org.springframework.web.WebApplicationInitializer[] (even if you extend from a base class that already implements it).
A typical initializer for WebLogic should resemble the following example:
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/docker-compose.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/docker-compose.adoc
index 7edaa836be..8342b87f38 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/docker-compose.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/docker-compose.adoc
@@ -8,7 +8,7 @@ This section includes topics relating to the Docker Compose support in Spring Bo
[[howto.docker-compose.jdbc-url]]
== Customizing the JDBC URL
-When using `JdbcConnectionDetails` with Docker Compose, the parameters of the JDBC URL
+When using javadoc:org.springframework.boot.autoconfigure.jdbc.JdbcConnectionDetails[] with Docker Compose, the parameters of the JDBC URL
can be customized by applying the `org.springframework.boot.jdbc.parameters` label to the
service. For example:
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/http-clients.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/http-clients.adoc
index 27d80e6fde..536271c769 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/http-clients.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/http-clients.adoc
@@ -9,8 +9,8 @@ This section answers questions related to using them.
[[howto.http-clients.rest-template-proxy-configuration]]
== Configure RestTemplate to Use a Proxy
-As described in xref:reference:io/rest-client.adoc#io.rest-client.resttemplate.customization[RestTemplate Customization], you can use a `RestTemplateCustomizer` with `RestTemplateBuilder` to build a customized `RestTemplate`.
-This is the recommended approach for creating a `RestTemplate` configured to use a proxy.
+As described in xref:reference:io/rest-client.adoc#io.rest-client.resttemplate.customization[RestTemplate Customization], you can use a javadoc:org.springframework.boot.web.client.RestTemplateCustomizer[] with javadoc:org.springframework.boot.web.client.RestTemplateBuilder[] to build a customized javadoc:org.springframework.web.client.RestTemplate[].
+This is the recommended approach for creating a javadoc:org.springframework.web.client.RestTemplate[] configured to use a proxy.
The exact details of the proxy configuration depend on the underlying client request factory that is being used.
@@ -19,11 +19,11 @@ The exact details of the proxy configuration depend on the underlying client req
[[howto.http-clients.webclient-reactor-netty-customization]]
== Configure the TcpClient used by a Reactor Netty-based WebClient
-When Reactor Netty is on the classpath a Reactor Netty-based `WebClient` is auto-configured.
-To customize the client's handling of network connections, provide a `ClientHttpConnector` bean.
-The following example configures a 60 second connect timeout and adds a `ReadTimeoutHandler`:
+When Reactor Netty is on the classpath a Reactor Netty-based javadoc:org.springframework.web.reactive.function.client.WebClient[] is auto-configured.
+To customize the client's handling of network connections, provide a javadoc:org.springframework.http.client.reactive.ClientHttpConnector[] bean.
+The following example configures a 60 second connect timeout and adds a javadoc:io.netty.handler.timeout.ReadTimeoutHandler[]:
include-code::MyReactorNettyClientConfiguration[]
-TIP: Note the use of `ReactorResourceFactory` for the connection provider and event loop resources.
+TIP: Note the use of javadoc:org.springframework.http.client.ReactorResourceFactory[] for the connection provider and event loop resources.
This ensures efficient sharing of resources for the server receiving requests and the client making requests.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/jersey.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/jersey.adoc
index c4ed028ad7..ba6de63408 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/jersey.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/jersey.adoc
@@ -10,7 +10,7 @@ Spring Security can be used to secure a Jersey-based web application in much the
However, if you want to use Spring Security's method-level security with Jersey, you must configure Jersey to use `setStatus(int)` rather `sendError(int)`.
This prevents Jersey from committing the response before Spring Security has had an opportunity to report an authentication or authorization failure to the client.
-The `jersey.config.server.response.setStatusOverSendError` property must be set to `true` on the application's `ResourceConfig` bean, as shown in the following example:
+The `jersey.config.server.response.setStatusOverSendError` property must be set to `true` on the application's javadoc:org.glassfish.jersey.server.ResourceConfig[] bean, as shown in the following example:
include-code::JerseySetStatusOverSendErrorConfig[]
@@ -21,6 +21,6 @@ include-code::JerseySetStatusOverSendErrorConfig[]
To use Jersey alongside another web framework, such as Spring MVC, it should be configured so that it will allow the other framework to handle requests that it cannot handle.
First, configure Jersey to use a filter rather than a servlet by configuring the configprop:spring.jersey.type[] application property with a value of `filter`.
-Second, configure your `ResourceConfig` to forward requests that would have resulted in a 404, as shown in the following example.
+Second, configure your javadoc:org.glassfish.jersey.server.ResourceConfig[] to forward requests that would have resulted in a 404, as shown in the following example.
include-code::JerseyConfig[]
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/logging.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/logging.adoc
index 38370ada44..ed391a4927 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/logging.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/logging.adoc
@@ -15,7 +15,7 @@ If you use Maven, the following dependency adds logging for you:
----
-Spring Boot has a `LoggingSystem` abstraction that attempts to configure logging based on the content of the classpath.
+Spring Boot has a javadoc:org.springframework.boot.logging.LoggingSystem[] abstraction that attempts to configure logging based on the content of the classpath.
If Logback is available, it is the first choice.
If the only change you need to make to logging is to set the levels of various loggers, you can do so in `application.properties` by using the "logging.level" prefix, as shown in the following example:
@@ -30,7 +30,7 @@ logging:
You can also set the location of a file to which the log will be written (in addition to the console) by using `logging.file.name`.
-To configure the more fine-grained settings of a logging system, you need to use the native configuration format supported by the `LoggingSystem` in question.
+To configure the more fine-grained settings of a logging system, you need to use the native configuration format supported by the javadoc:org.springframework.boot.logging.LoggingSystem[] in question.
By default, Spring Boot picks up the native configuration from its default location for the system (such as `classpath:logback.xml` for Logback), but you can set the location of the config file by using the configprop:logging.config[] property.
@@ -50,8 +50,8 @@ These includes are designed to allow certain common Spring Boot conventions to b
The following files are provided under `org/springframework/boot/logging/logback/`:
* `defaults.xml` - Provides conversion rules, pattern properties and common logger configurations.
-* `console-appender.xml` - Adds a `ConsoleAppender` using the `CONSOLE_LOG_PATTERN`.
-* `file-appender.xml` - Adds a `RollingFileAppender` using the `FILE_LOG_PATTERN` and `ROLLING_FILE_NAME_PATTERN` with appropriate settings.
+* `console-appender.xml` - Adds a javadoc:ch.qos.logback.core.ConsoleAppender[] using the `CONSOLE_LOG_PATTERN`.
+* `file-appender.xml` - Adds a javadoc:ch.qos.logback.core.rolling.RollingFileAppender[] using the `FILE_LOG_PATTERN` and `ROLLING_FILE_NAME_PATTERN` with appropriate settings.
In addition, a legacy `base.xml` file is provided for compatibility with earlier versions of Spring Boot.
@@ -70,7 +70,7 @@ A typical custom `logback.xml` file would look something like this:
----
-Your logback configuration file can also make use of System properties that the `LoggingSystem` takes care of creating for you:
+Your logback configuration file can also make use of System properties that the javadoc:org.springframework.boot.logging.LoggingSystem[] takes care of creating for you:
* `$\{PID}`: The current process ID.
* `$\{LOG_FILE}`: Whether `logging.file.name` was set in Boot's external configuration.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/messaging.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/messaging.adoc
index 79e994b330..1edd9a2e3c 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/messaging.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/messaging.adoc
@@ -10,8 +10,8 @@ This section answers questions that arise from using messaging with Spring Boot.
== Disable Transacted JMS Session
If your JMS broker does not support transacted sessions, you have to disable the support of transactions altogether.
-If you create your own `JmsListenerContainerFactory`, there is nothing to do, since, by default it cannot be transacted.
-If you want to use the `DefaultJmsListenerContainerFactoryConfigurer` to reuse Spring Boot's default, you can disable transacted sessions, as follows:
+If you create your own javadoc:org.springframework.jms.config.JmsListenerContainerFactory[], there is nothing to do, since, by default it cannot be transacted.
+If you want to use the javadoc:org.springframework.boot.autoconfigure.jms.DefaultJmsListenerContainerFactoryConfigurer[] to reuse Spring Boot's default, you can disable transacted sessions, as follows:
include-code::MyJmsConfiguration[]
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/native-image/testing-native-applications.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/native-image/testing-native-applications.adoc
index 16937b2867..1ccefe199d 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/native-image/testing-native-applications.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/native-image/testing-native-applications.adoc
@@ -40,7 +40,7 @@ For Gradle, you need to ensure that your build includes the `org.graalvm.buildto
If your application starts with the `spring.aot.enabled` property set to `true`, then you have higher confidence that it will work when converted to a native image.
You can also consider running integration tests against the running application.
-For example, you could use the Spring `WebClient` to call your application REST endpoints.
+For example, you could use the Spring javadoc:org.springframework.web.reactive.function.client.WebClient[] to call your application REST endpoints.
Or you might consider using a project like Selenium to check your application's HTML responses.
@@ -57,15 +57,15 @@ For example, you might choose to run native tests once a day.
Spring Framework includes ahead-of-time support for running tests.
All the usual Spring testing features work with native image tests.
-For example, you can continue to use the `@SpringBootTest` annotation.
+For example, you can continue to use the javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation] annotation.
You can also use Spring Boot xref:reference:testing/spring-boot-applications.adoc#testing.spring-boot-applications.autoconfigured-tests[test slices] to test only specific parts of your application.
Spring Framework's native testing support works in the following way:
-* Tests are analyzed in order to discover any `ApplicationContext` instances that will be required.
+* Tests are analyzed in order to discover any javadoc:org.springframework.context.ApplicationContext[] instances that will be required.
* Ahead-of-time processing is applied to each of these application contexts and assets are generated.
* A native image is created, with the generated assets being processed by GraalVM.
-* The native image also includes the JUnit `TestEngine` configured with a list of the discovered tests.
+* The native image also includes the JUnit javadoc:org.junit.platform.engine.TestEngine[] configured with a list of the discovered tests.
* The native image is started, triggering the engine which will run each test and report results.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/properties-and-configuration.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/properties-and-configuration.adoc
index 4ba6770872..0102396115 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/properties-and-configuration.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/properties-and-configuration.adoc
@@ -98,7 +98,7 @@ To use Spring property placeholders together with automatic expansion, escape th
[[howto.properties-and-configuration.externalize-configuration]]
== Externalize the Configuration of SpringApplication
-A `SpringApplication` has bean property setters, so you can use its Java API as you create the application to modify its behavior.
+A javadoc:org.springframework.boot.SpringApplication[] has bean property setters, so you can use its Java API as you create the application to modify its behavior.
Alternatively, you can externalize the configuration by setting properties in `+spring.main.*+`.
For example, in `application.properties`, you might have the following settings:
@@ -113,11 +113,11 @@ spring:
Then the Spring Boot banner is not printed on startup, and the application is not starting an embedded web server.
Properties defined in external configuration override and replace the values specified with the Java API, with the notable exception of the primary sources.
-Primary sources are those provided to the `SpringApplication` constructor:
+Primary sources are those provided to the javadoc:org.springframework.boot.SpringApplication[] constructor:
include-code::application/MyApplication[]
-Or to `sources(...)` method of a `SpringApplicationBuilder`:
+Or to `sources(...)` method of a javadoc:org.springframework.boot.builder.SpringApplicationBuilder[]:
include-code::builder/MyApplication[]
@@ -131,7 +131,7 @@ spring:
banner-mode: "console"
----
-The actual application will show the banner (as overridden by configuration) and use three sources for the `ApplicationContext`.
+The actual application will show the banner (as overridden by configuration) and use three sources for the javadoc:org.springframework.context.ApplicationContext[].
The application sources are:
. `MyApplication` (from the code)
@@ -143,13 +143,13 @@ The application sources are:
[[howto.properties-and-configuration.external-properties-location]]
== Change the Location of External Properties of an Application
-By default, properties from different sources are added to the Spring `Environment` in a defined order (see xref:reference:features/external-config.adoc[] in the "`Spring Boot Features`" section for the exact order).
+By default, properties from different sources are added to the Spring javadoc:org.springframework.core.env.Environment[] in a defined order (see xref:reference:features/external-config.adoc[] in the "`Spring Boot Features`" section for the exact order).
You can also provide the following System properties (or environment variables) to change the behavior:
* configprop:spring.config.name[] (configprop:spring.config.name[format=envvar]): Defaults to `application` as the root of the file name.
* configprop:spring.config.location[] (configprop:spring.config.location[format=envvar]): The file to load (such as a classpath resource or a URL).
- A separate `Environment` property source is set up for this document and it can be overridden by system properties, environment variables, or the command line.
+ A separate javadoc:org.springframework.core.env.Environment[] property source is set up for this document and it can be overridden by system properties, environment variables, or the command line.
No matter what you set in the environment, Spring Boot always loads `application.properties` as described above.
By default, if YAML is used, then files with the '`.yaml`' and '`.yml`' extensions are also added to the list.
@@ -174,7 +174,7 @@ TIP: If you inherit from the `spring-boot-starter-parent` POM, the default filte
If you have enabled Maven filtering for the `application.properties` directly, you may want to also change the default filter token to use https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html#delimiters[other delimiters].
NOTE: In this specific case, the port binding works in a PaaS environment such as Heroku or Cloud Foundry.
-On those two platforms, the `PORT` environment variable is set automatically and Spring can bind to capitalized synonyms for `Environment` properties.
+On those two platforms, the `PORT` environment variable is set automatically and Spring can bind to capitalized synonyms for javadoc:org.springframework.core.env.Environment[] properties.
@@ -197,7 +197,7 @@ server:
Create a file called `application.yaml` and put it in the root of your classpath.
Then add `snakeyaml` to your dependencies (Maven coordinates `org.yaml:snakeyaml`, already included if you use the `spring-boot-starter`).
-A YAML file is parsed to a Java `Map` (like a JSON object), and Spring Boot flattens the map so that it is one level deep and has period-separated keys, as many people are used to with `Properties` files in Java.
+A YAML file is parsed to a Java `Map` (like a JSON object), and Spring Boot flattens the map so that it is one level deep and has period-separated keys, as many people are used to with javadoc:java.util.Properties[] files in Java.
The preceding example YAML corresponds to the following `application.properties` file:
@@ -216,7 +216,7 @@ See xref:reference:features/external-config.adoc#features.external-config.yaml[]
[[howto.properties-and-configuration.set-active-spring-profiles]]
== Set the Active Spring Profiles
-The Spring `Environment` has an API for this, but you would normally set a System property (configprop:spring.profiles.active[]) or an OS environment variable (configprop:spring.profiles.active[format=envvar]).
+The Spring javadoc:org.springframework.core.env.Environment[] has an API for this, but you would normally set a System property (configprop:spring.profiles.active[]) or an OS environment variable (configprop:spring.profiles.active[format=envvar]).
Also, you can launch your application with a `-D` argument (remember to put it before the main class or jar archive), as follows:
[source,shell]
@@ -302,8 +302,8 @@ Later values override earlier values.
Spring Boot binds external properties from `application.properties` (or YAML files and other places) into an application at runtime.
There is not (and technically cannot be) an exhaustive list of all supported properties in a single location, because contributions can come from additional jar files on your classpath.
-A running application with the Actuator features has a `configprops` endpoint that shows all the bound and bindable properties available through `@ConfigurationProperties`.
+A running application with the Actuator features has a `configprops` endpoint that shows all the bound and bindable properties available through javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation].
The appendix includes an xref:appendix:application-properties/index.adoc[`application.properties`] example with a list of the most common properties supported by Spring Boot.
-The definitive list comes from searching the source code for `@ConfigurationProperties` and `@Value` annotations as well as the occasional use of `Binder`.
+The definitive list comes from searching the source code for javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] and javadoc:org.springframework.beans.factory.annotation.Value[format=annotation] annotations as well as the occasional use of javadoc:org.springframework.boot.context.properties.bind.Binder[].
For more about the exact ordering of loading properties, see xref:reference:features/external-config.adoc[].
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/security.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/security.adoc
index 3aa2112aa6..a5ef1e6b09 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/security.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/security.adoc
@@ -10,17 +10,17 @@ For more about Spring Security, see the {url-spring-security-site}[Spring Securi
[[howto.security.switch-off-spring-boot-configuration]]
== Switch Off the Spring Boot Security Configuration
-If you define a `@Configuration` with a `SecurityFilterChain` bean in your application, this action switches off the default webapp security settings in Spring Boot.
+If you define a javadoc:org.springframework.context.annotation.Configuration[format=annotation] with a javadoc:org.springframework.security.web.SecurityFilterChain[] bean in your application, this action switches off the default webapp security settings in Spring Boot.
[[howto.security.change-user-details-service-and-add-user-accounts]]
== Change the UserDetailsService and Add User Accounts
-If you provide a `@Bean` of type `AuthenticationManager`, `AuthenticationProvider`, or `UserDetailsService`, the default `@Bean` for `InMemoryUserDetailsManager` is not created.
+If you provide a javadoc:org.springframework.context.annotation.Bean[format=annotation] of type javadoc:org.springframework.security.authentication.AuthenticationManager[], javadoc:org.springframework.security.authentication.AuthenticationProvider[], or javadoc:org.springframework.security.core.userdetails.UserDetailsService[], the default javadoc:org.springframework.context.annotation.Bean[format=annotation] for javadoc:org.springframework.security.provisioning.InMemoryUserDetailsManager[] is not created.
This means you have the full feature set of Spring Security available (such as {url-spring-security-docs}/servlet/authentication/index.html[various authentication options]).
-The easiest way to add user accounts is by providing your own `UserDetailsService` bean.
+The easiest way to add user accounts is by providing your own javadoc:org.springframework.security.core.userdetails.UserDetailsService[] bean.
@@ -28,7 +28,7 @@ The easiest way to add user accounts is by providing your own `UserDetailsServic
== Enable HTTPS When Running Behind a Proxy Server
Ensuring that all your main endpoints are only available over HTTPS is an important chore for any application.
-If you use Tomcat as a servlet container, then Spring Boot adds Tomcat's own `RemoteIpValve` automatically if it detects some environment settings, allowing you to rely on the `HttpServletRequest` to report whether it is secure or not (even downstream of a proxy server that handles the real SSL termination).
+If you use Tomcat as a servlet container, then Spring Boot adds Tomcat's own javadoc:org.apache.catalina.valves.RemoteIpValve[] automatically if it detects some environment settings, allowing you to rely on the javadoc:jakarta.servlet.http.HttpServletRequest[] to report whether it is secure or not (even downstream of a proxy server that handles the real SSL termination).
The standard behavior is determined by the presence or absence of certain request headers (`x-forwarded-for` and `x-forwarded-proto`), whose names are conventional, so it should work with most front-end proxies.
You can switch on the valve by adding some entries to `application.properties`, as shown in the following example:
@@ -42,8 +42,8 @@ server:
----
(The presence of either of those properties switches on the valve.
-Alternatively, you can add the `RemoteIpValve` by customizing the `TomcatServletWebServerFactory` using a `WebServerFactoryCustomizer` bean.)
+Alternatively, you can add the javadoc:org.apache.catalina.valves.RemoteIpValve[] by customizing the javadoc:org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory[] using a javadoc:org.springframework.boot.web.server.WebServerFactoryCustomizer[] bean.)
-To configure Spring Security to require a secure channel for all (or some) requests, consider adding your own `SecurityFilterChain` bean that adds the following `HttpSecurity` configuration:
+To configure Spring Security to require a secure channel for all (or some) requests, consider adding your own javadoc:org.springframework.security.web.SecurityFilterChain[] bean that adds the following javadoc:org.springframework.security.config.annotation.web.builders.HttpSecurity[] configuration:
include-code::MySecurityConfig[]
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/spring-mvc.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/spring-mvc.adoc
index 372b056490..7e0a49b4c5 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/spring-mvc.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/spring-mvc.adoc
@@ -10,7 +10,7 @@ This section answers common questions about Spring MVC and Spring Boot.
[[howto.spring-mvc.write-json-rest-service]]
== Write a JSON REST Service
-Any Spring `@RestController` in a Spring Boot application should render JSON response by default as long as Jackson2 is on the classpath, as shown in the following example:
+Any Spring javadoc:org.springframework.web.bind.annotation.RestController[format=annotation] in a Spring Boot application should render JSON response by default as long as Jackson2 is on the classpath, as shown in the following example:
include-code::MyController[]
@@ -34,7 +34,7 @@ To use the Jackson XML renderer, add the following dependency to your project:
----
-If Jackson's XML extension is not available and JAXB is available, XML can be rendered with the additional requirement of having `MyThing` annotated as `@XmlRootElement`, as shown in the following example:
+If Jackson's XML extension is not available and JAXB is available, XML can be rendered with the additional requirement of having `MyThing` annotated as javadoc:jakarta.xml.bind.annotation.XmlRootElement[format=annotation], as shown in the following example:
include-code::MyThing[]
@@ -55,10 +55,10 @@ NOTE: To get the server to render XML instead of JSON, you might have to send an
[[howto.spring-mvc.customize-jackson-objectmapper]]
== Customize the Jackson ObjectMapper
-Spring MVC (client and server side) uses `HttpMessageConverters` to negotiate content conversion in an HTTP exchange.
-If Jackson is on the classpath, you already get the default converter(s) provided by `Jackson2ObjectMapperBuilder`, an instance of which is auto-configured for you.
+Spring MVC (client and server side) uses javadoc:org.springframework.boot.autoconfigure.http.HttpMessageConverters[] to negotiate content conversion in an HTTP exchange.
+If Jackson is on the classpath, you already get the default converter(s) provided by javadoc:org.springframework.http.converter.json.Jackson2ObjectMapperBuilder[], an instance of which is auto-configured for you.
-The `ObjectMapper` (or `XmlMapper` for Jackson XML converter) instance (created by default) has the following customized properties:
+The javadoc:com.fasterxml.jackson.databind.ObjectMapper[] (or javadoc:com.fasterxml.jackson.dataformat.xml.XmlMapper[] for Jackson XML converter) instance (created by default) has the following customized properties:
* `MapperFeature.DEFAULT_VIEW_INCLUSION` is disabled
* `DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES` is disabled
@@ -67,22 +67,22 @@ The `ObjectMapper` (or `XmlMapper` for Jackson XML converter) instance (created
Spring Boot also has some features to make it easier to customize this behavior.
-You can configure the `ObjectMapper` and `XmlMapper` instances by using the environment.
+You can configure the javadoc:com.fasterxml.jackson.databind.ObjectMapper[] and javadoc:com.fasterxml.jackson.dataformat.xml.XmlMapper[] instances by using the environment.
Jackson provides an extensive suite of on/off features that can be used to configure various aspects of its processing.
These features are described in several enums (in Jackson) that map onto properties in the environment:
|===
| Enum | Property | Values
-| `com.fasterxml.jackson.databind.cfg.EnumFeature`
+| javadoc:com.fasterxml.jackson.databind.cfg.EnumFeature[]
| `spring.jackson.datatype.enum.`
| `true`, `false`
-| `com.fasterxml.jackson.databind.cfg.JsonNodeFeature`
+| javadoc:com.fasterxml.jackson.databind.cfg.JsonNodeFeature[]
| `spring.jackson.datatype.json-node.`
| `true`, `false`
-| `com.fasterxml.jackson.databind.DeserializationFeature`
+| javadoc:com.fasterxml.jackson.databind.DeserializationFeature[]
| `spring.jackson.deserialization.`
| `true`, `false`
@@ -90,7 +90,7 @@ These features are described in several enums (in Jackson) that map onto propert
| `spring.jackson.generator.`
| `true`, `false`
-| `com.fasterxml.jackson.databind.MapperFeature`
+| javadoc:com.fasterxml.jackson.databind.MapperFeature[]
| `spring.jackson.mapper.`
| `true`, `false`
@@ -98,7 +98,7 @@ These features are described in several enums (in Jackson) that map onto propert
| `spring.jackson.parser.`
| `true`, `false`
-| `com.fasterxml.jackson.databind.SerializationFeature`
+| javadoc:com.fasterxml.jackson.databind.SerializationFeature[]
| `spring.jackson.serialization.`
| `true`, `false`
@@ -110,20 +110,20 @@ These features are described in several enums (in Jackson) that map onto propert
For example, to enable pretty print, set `spring.jackson.serialization.indent_output=true`.
Note that, thanks to the use of xref:reference:features/external-config.adoc#features.external-config.typesafe-configuration-properties.relaxed-binding[relaxed binding], the case of `indent_output` does not have to match the case of the corresponding enum constant, which is `INDENT_OUTPUT`.
-This environment-based configuration is applied to the auto-configured `Jackson2ObjectMapperBuilder` bean and applies to any mappers created by using the builder, including the auto-configured `ObjectMapper` bean.
+This environment-based configuration is applied to the auto-configured javadoc:org.springframework.http.converter.json.Jackson2ObjectMapperBuilder[] bean and applies to any mappers created by using the builder, including the auto-configured javadoc:com.fasterxml.jackson.databind.ObjectMapper[] bean.
-The context's `Jackson2ObjectMapperBuilder` can be customized by one or more `Jackson2ObjectMapperBuilderCustomizer` beans.
+The context's javadoc:org.springframework.http.converter.json.Jackson2ObjectMapperBuilder[] can be customized by one or more javadoc:org.springframework.boot.autoconfigure.jackson.Jackson2ObjectMapperBuilderCustomizer[] beans.
Such customizer beans can be ordered (Boot's own customizer has an order of 0), letting additional customization be applied both before and after Boot's customization.
-Any beans of type `com.fasterxml.jackson.databind.Module` are automatically registered with the auto-configured `Jackson2ObjectMapperBuilder` and are applied to any `ObjectMapper` instances that it creates.
+Any beans of type javadoc:com.fasterxml.jackson.databind.Module[] are automatically registered with the auto-configured javadoc:org.springframework.http.converter.json.Jackson2ObjectMapperBuilder[] and are applied to any javadoc:com.fasterxml.jackson.databind.ObjectMapper[] instances that it creates.
This provides a global mechanism for contributing custom modules when you add new features to your application.
-If you want to replace the default `ObjectMapper` completely, either define a `@Bean` of that type or, if you prefer the builder-based approach, define a `Jackson2ObjectMapperBuilder` `@Bean`.
-When defining an `ObjectMapper` bean, marking it as `@Primary` is recommended as the auto-configuration's `ObjectMapper` that it will replace is `@Primary`.
-Note that, in either case, doing so disables all auto-configuration of the `ObjectMapper`.
+If you want to replace the default javadoc:com.fasterxml.jackson.databind.ObjectMapper[] completely, either define a javadoc:org.springframework.context.annotation.Bean[format=annotation] of that type or, if you prefer the builder-based approach, define a javadoc:org.springframework.http.converter.json.Jackson2ObjectMapperBuilder[] javadoc:org.springframework.context.annotation.Bean[format=annotation].
+When defining an javadoc:com.fasterxml.jackson.databind.ObjectMapper[] bean, marking it as javadoc:org.springframework.context.annotation.Primary[format=annotation] is recommended as the auto-configuration's javadoc:com.fasterxml.jackson.databind.ObjectMapper[] that it will replace is javadoc:org.springframework.context.annotation.Primary[format=annotation].
+Note that, in either case, doing so disables all auto-configuration of the javadoc:com.fasterxml.jackson.databind.ObjectMapper[].
-If you provide any `@Beans` of type `MappingJackson2HttpMessageConverter`, they replace the default value in the MVC configuration.
-Also, a convenience bean of type `HttpMessageConverters` is provided (and is always available if you use the default MVC configuration).
+If you provide any javadoc:java.beans.Beans[format=annotation] of type javadoc:org.springframework.http.converter.json.MappingJackson2HttpMessageConverter[], they replace the default value in the MVC configuration.
+Also, a convenience bean of type javadoc:org.springframework.boot.autoconfigure.http.HttpMessageConverters[] is provided (and is always available if you use the default MVC configuration).
It has some useful methods to access the default and user-enhanced message converters.
See the xref:spring-mvc.adoc#howto.spring-mvc.customize-responsebody-rendering[] section and the {code-spring-boot-autoconfigure-src}/web/servlet/WebMvcAutoConfiguration.java[`WebMvcAutoConfiguration`] source code for more details.
@@ -133,15 +133,15 @@ See the xref:spring-mvc.adoc#howto.spring-mvc.customize-responsebody-rendering[]
[[howto.spring-mvc.customize-responsebody-rendering]]
== Customize the @ResponseBody Rendering
-Spring uses `HttpMessageConverters` to render `@ResponseBody` (or responses from `@RestController`).
+Spring uses javadoc:org.springframework.boot.autoconfigure.http.HttpMessageConverters[] to render javadoc:org.springframework.web.bind.annotation.ResponseBody[format=annotation] (or responses from javadoc:org.springframework.web.bind.annotation.RestController[format=annotation]).
You can contribute additional converters by adding beans of the appropriate type in a Spring Boot context.
-If a bean you add is of a type that would have been included by default anyway (such as `MappingJackson2HttpMessageConverter` for JSON conversions), it replaces the default value.
-A convenience bean of type `HttpMessageConverters` is provided and is always available if you use the default MVC configuration.
-It has some useful methods to access the default and user-enhanced message converters (For example, it can be useful if you want to manually inject them into a custom `RestTemplate`).
+If a bean you add is of a type that would have been included by default anyway (such as javadoc:org.springframework.http.converter.json.MappingJackson2HttpMessageConverter[] for JSON conversions), it replaces the default value.
+A convenience bean of type javadoc:org.springframework.boot.autoconfigure.http.HttpMessageConverters[] is provided and is always available if you use the default MVC configuration.
+It has some useful methods to access the default and user-enhanced message converters (For example, it can be useful if you want to manually inject them into a custom javadoc:org.springframework.web.client.RestTemplate[]).
-As in normal MVC usage, any `WebMvcConfigurer` beans that you provide can also contribute converters by overriding the `configureMessageConverters` method.
+As in normal MVC usage, any javadoc:org.springframework.web.servlet.config.annotation.WebMvcConfigurer[] beans that you provide can also contribute converters by overriding the `configureMessageConverters` method.
However, unlike with normal MVC, you can supply only additional converters that you need (because Spring Boot uses the same mechanism to contribute its defaults).
-Finally, if you opt out of the default Spring Boot MVC configuration by providing your own `@EnableWebMvc` configuration, you can take control completely and do everything manually by using `getMessageConverters` from `WebMvcConfigurationSupport`.
+Finally, if you opt out of the default Spring Boot MVC configuration by providing your own javadoc:org.springframework.web.servlet.config.annotation.EnableWebMvc[format=annotation] configuration, you can take control completely and do everything manually by using `getMessageConverters` from javadoc:org.springframework.web.servlet.config.annotation.WebMvcConfigurationSupport[].
See the {code-spring-boot-autoconfigure-src}/web/servlet/WebMvcAutoConfiguration.java[`WebMvcAutoConfiguration`] source code for more details.
@@ -150,12 +150,12 @@ See the {code-spring-boot-autoconfigure-src}/web/servlet/WebMvcAutoConfiguration
[[howto.spring-mvc.multipart-file-uploads]]
== Handling Multipart File Uploads
-Spring Boot embraces the servlet 5 `jakarta.servlet.http.Part` API to support uploading files.
+Spring Boot embraces the servlet 5 javadoc:jakarta.servlet.http.Part[] API to support uploading files.
By default, Spring Boot configures Spring MVC with a maximum size of 1MB per file and a maximum of 10MB of file data in a single request.
-You may override these values, the location to which intermediate data is stored (for example, to the `/tmp` directory), and the threshold past which data is flushed to disk by using the properties exposed in the `MultipartProperties` class.
+You may override these values, the location to which intermediate data is stored (for example, to the `/tmp` directory), and the threshold past which data is flushed to disk by using the properties exposed in the javadoc:org.springframework.boot.autoconfigure.web.servlet.MultipartProperties[] class.
For example, if you want to specify that files be unlimited, set the configprop:spring.servlet.multipart.max-file-size[] property to `-1`.
-The multipart support is helpful when you want to receive multipart encoded file data as a `@RequestParam`-annotated parameter of type `MultipartFile` in a Spring MVC controller handler method.
+The multipart support is helpful when you want to receive multipart encoded file data as a javadoc:org.springframework.web.bind.annotation.RequestParam[format=annotation]-annotated parameter of type javadoc:org.springframework.web.multipart.MultipartFile[] in a Spring MVC controller handler method.
See the {code-spring-boot-autoconfigure-src}/web/servlet/MultipartAutoConfiguration.java[`MultipartAutoConfiguration`] source for more details.
@@ -177,17 +177,17 @@ spring:
path: "/mypath"
----
-If you have additional servlets you can declare a `@Bean` of type `Servlet` or `ServletRegistrationBean` for each and Spring Boot will register them transparently to the container.
-Because servlets are registered that way, they can be mapped to a sub-context of the `DispatcherServlet` without invoking it.
+If you have additional servlets you can declare a javadoc:org.springframework.context.annotation.Bean[format=annotation] of type javadoc:jakarta.servlet.Servlet[] or javadoc:org.springframework.boot.web.servlet.ServletRegistrationBean[] for each and Spring Boot will register them transparently to the container.
+Because servlets are registered that way, they can be mapped to a sub-context of the javadoc:org.springframework.web.servlet.DispatcherServlet[] without invoking it.
-Configuring the `DispatcherServlet` yourself is unusual but if you really need to do it, a `@Bean` of type `DispatcherServletPath` must be provided as well to provide the path of your custom `DispatcherServlet`.
+Configuring the javadoc:org.springframework.web.servlet.DispatcherServlet[] yourself is unusual but if you really need to do it, a javadoc:org.springframework.context.annotation.Bean[format=annotation] of type javadoc:org.springframework.boot.autoconfigure.web.servlet.DispatcherServletPath[] must be provided as well to provide the path of your custom javadoc:org.springframework.web.servlet.DispatcherServlet[].
[[howto.spring-mvc.switch-off-default-configuration]]
== Switch Off the Default MVC Configuration
-The easiest way to take complete control over MVC configuration is to provide your own `@Configuration` with the `@EnableWebMvc` annotation.
+The easiest way to take complete control over MVC configuration is to provide your own javadoc:org.springframework.context.annotation.Configuration[format=annotation] with the javadoc:org.springframework.web.servlet.config.annotation.EnableWebMvc[format=annotation] annotation.
Doing so leaves all MVC configuration in your hands.
@@ -195,45 +195,45 @@ Doing so leaves all MVC configuration in your hands.
[[howto.spring-mvc.customize-view-resolvers]]
== Customize ViewResolvers
-A `ViewResolver` is a core component of Spring MVC, translating view names in `@Controller` to actual `View` implementations.
-Note that view resolvers are mainly used in UI applications, rather than REST-style services (a `View` is not used to render a `@ResponseBody`).
-There are many implementations of `ViewResolver` to choose from, and Spring on its own is not opinionated about which ones you should use.
+A javadoc:org.springframework.web.servlet.ViewResolver[] is a core component of Spring MVC, translating view names in javadoc:org.springframework.stereotype.Controller[format=annotation] to actual javadoc:org.springframework.web.servlet.View[] implementations.
+Note that view resolvers are mainly used in UI applications, rather than REST-style services (a javadoc:org.springframework.web.servlet.View[] is not used to render a javadoc:org.springframework.web.bind.annotation.ResponseBody[format=annotation]).
+There are many implementations of javadoc:org.springframework.web.servlet.ViewResolver[] to choose from, and Spring on its own is not opinionated about which ones you should use.
Spring Boot, on the other hand, installs one or two for you, depending on what it finds on the classpath and in the application context.
-The `DispatcherServlet` uses all the resolvers it finds in the application context, trying each one in turn until it gets a result.
+The javadoc:org.springframework.web.servlet.DispatcherServlet[] uses all the resolvers it finds in the application context, trying each one in turn until it gets a result.
If you add your own, you have to be aware of the order and in which position your resolver is added.
-`WebMvcAutoConfiguration` adds the following `ViewResolvers` to your context:
+javadoc:org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration[] adds the following javadoc:org.springframework.web.servlet.ViewResolver[] beans to your context:
-* An `InternalResourceViewResolver` named '`defaultViewResolver`'.
+* An javadoc:org.springframework.web.servlet.view.InternalResourceViewResolver[] named '`defaultViewResolver`'.
This one locates physical resources that can be rendered by using the `DefaultServlet` (including static resources and JSP pages, if you use those).
It applies a prefix and a suffix to the view name and then looks for a physical resource with that path in the servlet context (the defaults are both empty but are accessible for external configuration through `spring.mvc.view.prefix` and `spring.mvc.view.suffix`).
You can override it by providing a bean of the same type.
-* A `BeanNameViewResolver` named '`beanNameViewResolver`'.
- This is a useful member of the view resolver chain and picks up any beans with the same name as the `View` being resolved.
+* A javadoc:org.springframework.web.servlet.view.BeanNameViewResolver[] named '`beanNameViewResolver`'.
+ This is a useful member of the view resolver chain and picks up any beans with the same name as the javadoc:org.springframework.web.servlet.View[] being resolved.
It should not be necessary to override or replace it.
-* A `ContentNegotiatingViewResolver` named '`viewResolver`' is added only if there *are* actually beans of type `View` present.
+* A javadoc:org.springframework.web.servlet.view.ContentNegotiatingViewResolver[] named '`viewResolver`' is added only if there *are* actually beans of type javadoc:org.springframework.web.servlet.View[] present.
This is a composite resolver, delegating to all the others and attempting to find a match to the '`Accept`' HTTP header sent by the client.
- There is a useful https://spring.io/blog/2013/06/03/content-negotiation-using-views[blog about `ContentNegotiatingViewResolver`] that you might like to study to learn more, and you might also look at the source code for detail.
- You can switch off the auto-configured `ContentNegotiatingViewResolver` by defining a bean named '`viewResolver`'.
-* If you use Thymeleaf, you also have a `ThymeleafViewResolver` named '`thymeleafViewResolver`'.
+ There is a useful https://spring.io/blog/2013/06/03/content-negotiation-using-views[blog about javadoc:org.springframework.web.servlet.view.ContentNegotiatingViewResolver[]] that you might like to study to learn more, and you might also look at the source code for detail.
+ You can switch off the auto-configured javadoc:org.springframework.web.servlet.view.ContentNegotiatingViewResolver[] by defining a bean named '`viewResolver`'.
+* If you use Thymeleaf, you also have a javadoc:org.thymeleaf.spring6.view.ThymeleafViewResolver[] named '`thymeleafViewResolver`'.
It looks for resources by surrounding the view name with a prefix and suffix.
The prefix is `spring.thymeleaf.prefix`, and the suffix is `spring.thymeleaf.suffix`.
The values of the prefix and suffix default to '`classpath:/templates/`' and '`.html`', respectively.
- You can override `ThymeleafViewResolver` by providing a bean of the same name.
-* If you use FreeMarker, you also have a `FreeMarkerViewResolver` named '`freeMarkerViewResolver`'.
+ You can override javadoc:org.thymeleaf.spring6.view.ThymeleafViewResolver[] by providing a bean of the same name.
+* If you use FreeMarker, you also have a javadoc:org.springframework.web.servlet.view.freemarker.FreeMarkerViewResolver[] named '`freeMarkerViewResolver`'.
It looks for resources in a loader path (which is externalized to `spring.freemarker.templateLoaderPath` and has a default value of '`classpath:/templates/`') by surrounding the view name with a prefix and a suffix.
The prefix is externalized to `spring.freemarker.prefix`, and the suffix is externalized to `spring.freemarker.suffix`.
The default values of the prefix and suffix are empty and '`.ftlh`', respectively.
- You can override `FreeMarkerViewResolver` by providing a bean of the same name.
-* If you use Groovy templates (actually, if `groovy-templates` is on your classpath), you also have a `GroovyMarkupViewResolver` named '`groovyMarkupViewResolver`'.
+ You can override javadoc:org.springframework.web.servlet.view.freemarker.FreeMarkerViewResolver[] by providing a bean of the same name.
+* If you use Groovy templates (actually, if `groovy-templates` is on your classpath), you also have a javadoc:org.springframework.web.servlet.view.groovy.GroovyMarkupViewResolver[] named '`groovyMarkupViewResolver`'.
It looks for resources in a loader path by surrounding the view name with a prefix and suffix (externalized to `spring.groovy.template.prefix` and `spring.groovy.template.suffix`).
The prefix and suffix have default values of '`classpath:/templates/`' and '`.tpl`', respectively.
- You can override `GroovyMarkupViewResolver` by providing a bean of the same name.
-* If you use Mustache, you also have a `MustacheViewResolver` named '`mustacheViewResolver`'.
+ You can override javadoc:org.springframework.web.servlet.view.groovy.GroovyMarkupViewResolver[] by providing a bean of the same name.
+* If you use Mustache, you also have a javadoc:org.springframework.boot.web.servlet.view.MustacheViewResolver[] named '`mustacheViewResolver`'.
It looks for resources by surrounding the view name with a prefix and suffix.
The prefix is `spring.mustache.prefix`, and the suffix is `spring.mustache.suffix`.
The values of the prefix and suffix default to '`classpath:/templates/`' and '`.mustache`', respectively.
- You can override `MustacheViewResolver` by providing a bean of the same name.
+ You can override javadoc:org.springframework.boot.web.servlet.view.MustacheViewResolver[] by providing a bean of the same name.
For more detail, see the following sections:
@@ -256,8 +256,8 @@ Note that Spring Boot still tries to resolve the error view, so you should proba
Overriding the error page with your own depends on the templating technology that you use.
For example, if you use Thymeleaf, you can add an `error.html` template.
If you use FreeMarker, you can add an `error.ftlh` template.
-In general, you need a `View` that resolves with a name of `error` or a `@Controller` that handles the `/error` path.
-Unless you replaced some of the default configuration, you should find a `BeanNameViewResolver` in your `ApplicationContext`, so a `@Bean` named `error` would be one way of doing that.
+In general, you need a javadoc:org.springframework.web.servlet.View[] that resolves with a name of `error` or a javadoc:org.springframework.stereotype.Controller[format=annotation] that handles the `/error` path.
+Unless you replaced some of the default configuration, you should find a javadoc:org.springframework.web.servlet.view.BeanNameViewResolver[] in your javadoc:org.springframework.context.ApplicationContext[], so a javadoc:org.springframework.context.annotation.Bean[format=annotation] named `error` would be one way of doing that.
See {code-spring-boot-autoconfigure-src}/web/servlet/error/ErrorMvcAutoConfiguration.java[`ErrorMvcAutoConfiguration`] for more options.
See also the section on xref:reference:web/servlet.adoc#web.servlet.spring-mvc.error-handling[] for details of how to register handlers in the servlet container.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/testing.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/testing.adoc
index 60647b045a..1223b88262 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/testing.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/testing.adoc
@@ -14,7 +14,7 @@ For example, the test in the snippet below will run with an authenticated user t
include-code::MySecurityTests[]
-Spring Security provides comprehensive integration with Spring MVC Test, and this can also be used when testing controllers using the `@WebMvcTest` slice and `MockMvc`.
+Spring Security provides comprehensive integration with Spring MVC Test, and this can also be used when testing controllers using the javadoc:org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest[format=annotation] slice and javadoc:org.springframework.test.web.servlet.MockMvc[].
For additional details on Spring Security's testing support, see Spring Security's {url-spring-security-docs}/servlet/test/index.html[reference documentation].
@@ -22,18 +22,18 @@ For additional details on Spring Security's testing support, see Spring Security
[[howto.testing.slice-tests]]
-== Structure `@Configuration` Classes for Inclusion in Slice Tests
+== Structure javadoc:org.springframework.context.annotation.Configuration[format=annotation] Classes for Inclusion in Slice Tests
Slice tests work by restricting Spring Framework's component scanning to a limited set of components based on their type.
-For any beans that are not created through component scanning, for example, beans that are created using the `@Bean` annotation, slice tests will not be able to include/exclude them from the application context.
+For any beans that are not created through component scanning, for example, beans that are created using the javadoc:org.springframework.context.annotation.Bean[format=annotation] annotation, slice tests will not be able to include/exclude them from the application context.
Consider this example:
include-code::MyConfiguration[]
-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 javadoc:org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest[format=annotation] for an application with the above javadoc:org.springframework.context.annotation.Configuration[format=annotation] class, you might expect to have the javadoc:org.springframework.security.web.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(MyConfiguration.class)`.
-This will load all the beans in `MyConfiguration` including the `HikariDataSource` bean which isn't required when testing the web tier.
+This will load all the beans in `MyConfiguration` including the javadoc:com.zaxxer.hikari.HikariDataSource[] bean which isn't required when testing the web tier.
Splitting the configuration class into two will enable importing just the security configuration.
include-code::MySecurityConfiguration[]
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/webserver.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/webserver.adoc
index 78037ad24d..df2d4bd962 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/webserver.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/how-to/pages/webserver.adoc
@@ -55,7 +55,7 @@ dependencies {
}
----
-NOTE: `spring-boot-starter-reactor-netty` is required to use the `WebClient` class, so you may need to keep a dependency on Netty even when you need to include a different HTTP server.
+NOTE: `spring-boot-starter-reactor-netty` is required to use the javadoc:org.springframework.web.reactive.function.client.WebClient[] class, so you may need to keep a dependency on Netty even when you need to include a different HTTP server.
@@ -63,7 +63,7 @@ NOTE: `spring-boot-starter-reactor-netty` is required to use the `WebClient` cla
== Disabling the Web Server
If your classpath contains the necessary bits to start a web server, Spring Boot will automatically start it.
-To disable this behavior configure the `WebApplicationType` in your `application.properties`, as shown in the following example:
+To disable this behavior configure the javadoc:org.springframework.boot.WebApplicationType[] in your `application.properties`, as shown in the following example:
[configprops,yaml]
----
@@ -78,9 +78,9 @@ spring:
== Change the HTTP Port
In a standalone application, the main HTTP port defaults to `8080` but can be set with configprop:server.port[] (for example, in `application.properties` or as a System property).
-Thanks to relaxed binding of `Environment` values, you can also use configprop:server.port[format=envvar] (for example, as an OS environment variable).
+Thanks to relaxed binding of javadoc:org.springframework.core.env.Environment[] values, you can also use configprop:server.port[format=envvar] (for example, as an OS environment variable).
-To switch off the HTTP endpoints completely but still create a `WebApplicationContext`, use `server.port=-1` (doing so is sometimes useful for testing).
+To switch off the HTTP endpoints completely but still create a javadoc:org.springframework.web.context.WebApplicationContext[], use `server.port=-1` (doing so is sometimes useful for testing).
For more details, see xref:reference:web/servlet.adoc#web.servlet.embedded-container.customizing[Customizing Embedded Servlet Containers] in the '`Spring Boot Features`' section, or the javadoc:org.springframework.boot.autoconfigure.web.ServerProperties[] class.
@@ -96,16 +96,16 @@ To scan for a free port (using OS natives to prevent clashes) use `server.port=0
[[howto.webserver.discover-port]]
== Discover the HTTP Port at Runtime
-You can access the port the server is running on from log output or from the `WebServerApplicationContext` through its `WebServer`.
-The best way to get that and be sure it has been initialized is to add a `@Bean` of type `ApplicationListener` and pull the container out of the event when it is published.
+You can access the port the server is running on from log output or from the javadoc:org.springframework.boot.web.context.WebServerApplicationContext[] through its javadoc:org.springframework.boot.web.server.WebServer[].
+The best way to get that and be sure it has been initialized is to add a javadoc:org.springframework.context.annotation.Bean[format=annotation] of type `ApplicationListener` and pull the container out of the event when it is published.
-Tests that use `@SpringBootTest(webEnvironment=WebEnvironment.RANDOM_PORT)` can also inject the actual port into a field by using the `@LocalServerPort` annotation, as shown in the following example:
+Tests that use `@SpringBootTest(webEnvironment=WebEnvironment.RANDOM_PORT)` can also inject the actual port into a field by using the javadoc:org.springframework.boot.test.web.server.LocalServerPort[format=annotation] annotation, as shown in the following example:
include-code::MyWebIntegrationTests[]
[NOTE]
====
-`@LocalServerPort` is a meta-annotation for `@Value("${local.server.port}")`.
+javadoc:org.springframework.boot.test.web.server.LocalServerPort[format=annotation] is a meta-annotation for `@Value("${local.server.port}")`.
Do not try to inject the port in a regular application.
As we just saw, the value is set only after the container has been initialized.
Contrary to a test, application code callbacks are processed early (before the value is actually available).
@@ -308,9 +308,9 @@ The example below is for Tomcat with the `spring-boot-starter-web` (servlet stac
include-code::MyTomcatWebServerCustomizer[]
NOTE: Spring Boot uses that infrastructure internally to auto-configure the server.
-Auto-configured `WebServerFactoryCustomizer` beans have an order of `0` and will be processed before any user-defined customizers, unless it has an explicit order that states otherwise.
+Auto-configured javadoc:org.springframework.boot.web.server.WebServerFactoryCustomizer[] beans have an order of `0` and will be processed before any user-defined customizers, unless it has an explicit order that states otherwise.
-Once you have got access to a `WebServerFactory` using the customizer, you can use it to configure specific parts, like connectors, server resources, or the server itself - all using server-specific APIs.
+Once you have got access to a javadoc:org.springframework.boot.web.server.WebServerFactory[] using the customizer, you can use it to configure specific parts, like connectors, server resources, or the server itself - all using server-specific APIs.
In addition Spring Boot provides:
@@ -320,23 +320,23 @@ In addition Spring Boot provides:
| Server | Servlet stack | Reactive stack
| Tomcat
-| `TomcatServletWebServerFactory`
-| `TomcatReactiveWebServerFactory`
+| javadoc:org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory[]
+| javadoc:org.springframework.boot.web.embedded.tomcat.TomcatReactiveWebServerFactory[]
| Jetty
-| `JettyServletWebServerFactory`
-| `JettyReactiveWebServerFactory`
+| javadoc:org.springframework.boot.web.embedded.jetty.JettyServletWebServerFactory[]
+| javadoc:org.springframework.boot.web.embedded.jetty.JettyReactiveWebServerFactory[]
| Undertow
-| `UndertowServletWebServerFactory`
-| `UndertowReactiveWebServerFactory`
+| javadoc:org.springframework.boot.web.embedded.undertow.UndertowServletWebServerFactory[]
+| javadoc:org.springframework.boot.web.embedded.undertow.UndertowReactiveWebServerFactory[]
| Reactor
| N/A
-| `NettyReactiveWebServerFactory`
+| javadoc:org.springframework.boot.web.embedded.netty.NettyReactiveWebServerFactory[]
|===
-As a last resort, you can also declare your own `WebServerFactory` bean, which will override the one provided by Spring Boot.
+As a last resort, you can also declare your own javadoc:org.springframework.boot.web.server.WebServerFactory[] bean, which will override the one provided by Spring Boot.
When you do so, auto-configured customizers are still applied on your custom factory, so use that option carefully.
@@ -344,7 +344,7 @@ When you do so, auto-configured customizers are still applied on your custom fac
[[howto.webserver.add-servlet-filter-listener]]
== Add a Servlet, Filter, or Listener to an Application
-In a servlet stack application, that is with the `spring-boot-starter-web`, there are two ways to add `Servlet`, `Filter`, `ServletContextListener`, and the other listeners supported by the Servlet API to your application:
+In a servlet stack application, that is with the `spring-boot-starter-web`, there are two ways to add javadoc:jakarta.servlet.Servlet[], javadoc:jakarta.servlet.Filter[], javadoc:jakarta.servlet.ServletContextListener[], and the other listeners supported by the Servlet API to your application:
* xref:webserver.adoc#howto.webserver.add-servlet-filter-listener.spring-bean[]
* xref:webserver.adoc#howto.webserver.add-servlet-filter-listener.using-scanning[]
@@ -354,13 +354,13 @@ In a servlet stack application, that is with the `spring-boot-starter-web`, ther
[[howto.webserver.add-servlet-filter-listener.spring-bean]]
=== Add a Servlet, Filter, or Listener by Using a Spring Bean
-To add a `Servlet`, `Filter`, or servlet `*Listener` by using a Spring bean, you must provide a `@Bean` definition for it.
+To add a javadoc:jakarta.servlet.Servlet[], javadoc:jakarta.servlet.Filter[], or servlet `*Listener` by using a Spring bean, you must provide a javadoc:org.springframework.context.annotation.Bean[format=annotation] definition for it.
Doing so can be very useful when you want to inject configuration or dependencies.
However, you must be very careful that they do not cause eager initialization of too many other beans, because they have to be installed in the container very early in the application lifecycle.
-(For example, it is not a good idea to have them depend on your `DataSource` or JPA configuration.)
+(For example, it is not a good idea to have them depend on your javadoc:javax.sql.DataSource[] or JPA configuration.)
You can work around such restrictions by initializing the beans lazily when first used instead of on initialization.
-In the case of filters and servlets, you can also add mappings and init parameters by adding a `FilterRegistrationBean` or a `ServletRegistrationBean` instead of or in addition to the underlying component.
+In the case of filters and servlets, you can also add mappings and init parameters by adding a javadoc:org.springframework.boot.web.servlet.FilterRegistrationBean[] or a javadoc:org.springframework.boot.web.servlet.ServletRegistrationBean[] instead of or in addition to the underlying component.
[NOTE]
====
@@ -375,8 +375,8 @@ Like any other Spring bean, you can define the order of servlet filter beans; pl
[[howto.webserver.add-servlet-filter-listener.spring-bean.disable]]
==== Disable Registration of a Servlet or Filter
-As xref:webserver.adoc#howto.webserver.add-servlet-filter-listener.spring-bean[described earlier], any `Servlet` or `Filter` beans are registered with the servlet container automatically.
-To disable registration of a particular `Filter` or `Servlet` bean, create a registration bean for it and mark it as disabled, as shown in the following example:
+As xref:webserver.adoc#howto.webserver.add-servlet-filter-listener.spring-bean[described earlier], any javadoc:jakarta.servlet.Servlet[] or javadoc:jakarta.servlet.Filter[] beans are registered with the servlet container automatically.
+To disable registration of a particular javadoc:jakarta.servlet.Filter[] or javadoc:jakarta.servlet.Servlet[] bean, create a registration bean for it and mark it as disabled, as shown in the following example:
include-code::MyFilterConfiguration[]
@@ -385,8 +385,8 @@ include-code::MyFilterConfiguration[]
[[howto.webserver.add-servlet-filter-listener.using-scanning]]
=== Add Servlets, Filters, and Listeners by Using Classpath Scanning
-`@WebServlet`, `@WebFilter`, and `@WebListener` annotated classes can be automatically registered with an embedded servlet container by annotating a `@Configuration` class with `@ServletComponentScan` and specifying the package(s) containing the components that you want to register.
-By default, `@ServletComponentScan` scans from the package of the annotated class.
+javadoc:jakarta.servlet.annotation.WebServlet[format=annotation], javadoc:jakarta.servlet.annotation.WebFilter[format=annotation], and javadoc:jakarta.servlet.annotation.WebListener[format=annotation] annotated classes can be automatically registered with an embedded servlet container by annotating a javadoc:org.springframework.context.annotation.Configuration[format=annotation] class with javadoc:org.springframework.boot.web.servlet.ServletComponentScan[format=annotation] and specifying the package(s) containing the components that you want to register.
+By default, javadoc:org.springframework.boot.web.servlet.ServletComponentScan[format=annotation] scans from the package of the annotated class.
@@ -498,14 +498,14 @@ server:
NOTE: You can trust all proxies by setting the `internal-proxies` to empty (but do not do so in production).
-You can take complete control of the configuration of Tomcat's `RemoteIpValve` by switching the automatic one off (to do so, set `server.forward-headers-strategy=NONE`) and adding a new valve instance using a `WebServerFactoryCustomizer` bean.
+You can take complete control of the configuration of Tomcat's javadoc:org.apache.catalina.valves.RemoteIpValve[] by switching the automatic one off (to do so, set `server.forward-headers-strategy=NONE`) and adding a new valve instance using a javadoc:org.springframework.boot.web.server.WebServerFactoryCustomizer[] bean.
[[howto.webserver.enable-multiple-connectors-in-tomcat]]
== Enable Multiple Connectors with Tomcat
-You can add an `org.apache.catalina.connector.Connector` to the `TomcatServletWebServerFactory`, which can allow multiple connectors, including HTTP and HTTPS connectors, as shown in the following example:
+You can add an javadoc:org.apache.catalina.connector.Connector[] to the javadoc:org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory[], which can allow multiple connectors, including HTTP and HTTPS connectors, as shown in the following example:
include-code::MyTomcatConfiguration[]
@@ -531,7 +531,7 @@ server:
[[howto.webserver.enable-multiple-listeners-in-undertow]]
== Enable Multiple Listeners with Undertow
-Add an `UndertowBuilderCustomizer` to the `UndertowServletWebServerFactory` and add a listener to the `Builder`, as shown in the following example:
+Add an javadoc:org.springframework.boot.web.embedded.undertow.UndertowBuilderCustomizer[] to the javadoc:org.springframework.boot.web.embedded.undertow.UndertowServletWebServerFactory[] and add a listener to the `io.undertow.Undertow.Builder`, as shown in the following example:
include-code::MyUndertowConfiguration[]
@@ -540,9 +540,9 @@ include-code::MyUndertowConfiguration[]
[[howto.webserver.create-websocket-endpoints-using-serverendpoint]]
== Create WebSocket Endpoints Using @ServerEndpoint
-If you want to use `@ServerEndpoint` in a Spring Boot application that used an embedded container, you must declare a single `ServerEndpointExporter` `@Bean`, as shown in the following example:
+If you want to use javadoc:jakarta.websocket.server.ServerEndpoint[format=annotation] in a Spring Boot application that used an embedded container, you must declare a single javadoc:org.springframework.web.socket.server.standard.ServerEndpointExporter[] javadoc:org.springframework.context.annotation.Bean[format=annotation], as shown in the following example:
include-code::MyWebSocketConfiguration[]
-The bean shown in the preceding example registers any `@ServerEndpoint` annotated beans with the underlying WebSocket container.
-When deployed to a standalone servlet container, this role is performed by a servlet container initializer, and the `ServerEndpointExporter` bean is not required.
+The bean shown in the preceding example registers any javadoc:jakarta.websocket.server.ServerEndpoint[format=annotation] annotated beans with the underlying WebSocket container.
+When deployed to a standalone servlet container, this role is performed by a servlet container initializer, and the javadoc:org.springframework.web.socket.server.standard.ServerEndpointExporter[] bean is not required.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/auditing.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/auditing.adoc
index 7c366cb29b..34926876d7 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/auditing.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/auditing.adoc
@@ -4,17 +4,17 @@
Once Spring Security is in play, Spring Boot Actuator has a flexible audit framework that publishes events (by default, "`authentication success`", "`failure`" and "`access denied`" exceptions).
This feature can be very useful for reporting and for implementing a lock-out policy based on authentication failures.
-You can enable auditing by providing a bean of type `AuditEventRepository` in your application's configuration.
-For convenience, Spring Boot offers an `InMemoryAuditEventRepository`.
-`InMemoryAuditEventRepository` has limited capabilities, and we recommend using it only for development environments.
-For production environments, consider creating your own alternative `AuditEventRepository` implementation.
+You can enable auditing by providing a bean of type javadoc:org.springframework.boot.actuate.audit.AuditEventRepository[] in your application's configuration.
+For convenience, Spring Boot offers an javadoc:org.springframework.boot.actuate.audit.InMemoryAuditEventRepository[].
+javadoc:org.springframework.boot.actuate.audit.InMemoryAuditEventRepository[] has limited capabilities, and we recommend using it only for development environments.
+For production environments, consider creating your own alternative javadoc:org.springframework.boot.actuate.audit.AuditEventRepository[] implementation.
[[actuator.auditing.custom]]
== Custom Auditing
-To customize published security events, you can provide your own implementations of `AbstractAuthenticationAuditListener` and `AbstractAuthorizationAuditListener`.
+To customize published security events, you can provide your own implementations of javadoc:org.springframework.boot.actuate.security.AbstractAuthenticationAuditListener[] and javadoc:org.springframework.boot.actuate.security.AbstractAuthorizationAuditListener[].
You can also use the audit services for your own business events.
-To do so, either inject the `AuditEventRepository` bean into your own components and use that directly or publish an `AuditApplicationEvent` with the Spring `ApplicationEventPublisher` (by implementing `ApplicationEventPublisherAware`).
+To do so, either inject the javadoc:org.springframework.boot.actuate.audit.AuditEventRepository[] bean into your own components and use that directly or publish an javadoc:org.springframework.boot.actuate.audit.listener.AuditApplicationEvent[] with the Spring javadoc:org.springframework.context.ApplicationEventPublisher[] (by implementing javadoc:org.springframework.context.ApplicationEventPublisherAware[]).
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/cloud-foundry.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/cloud-foundry.adoc
index a5e940dfe7..b3e73edf44 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/cloud-foundry.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/cloud-foundry.adoc
@@ -2,7 +2,7 @@
= Cloud Foundry Support
Spring Boot's actuator module includes additional support that is activated when you deploy to a compatible Cloud Foundry instance.
-The `/cloudfoundryapplication` path provides an alternative secured route to all `@Endpoint` beans.
+The `/cloudfoundryapplication` path provides an alternative secured route to all javadoc:org.springframework.boot.actuate.endpoint.annotation.Endpoint[format=annotation] beans.
The extended support lets Cloud Foundry management UIs (such as the web application that you can use to view deployed applications) be augmented with Spring Boot actuator information.
For example, an application status page can include full health information instead of the typical "`running`" or "`stopped`" status.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/endpoints.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/endpoints.adoc
index bb32866318..24b35b99ac 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/endpoints.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/endpoints.adoc
@@ -21,7 +21,7 @@ The following technology-agnostic endpoints are available:
| `auditevents`
| Exposes audit events information for the current application.
- Requires an `AuditEventRepository` bean.
+ Requires an javadoc:org.springframework.boot.actuate.audit.AuditEventRepository[] bean.
| `beans`
| Displays a complete list of all the Spring beans in your application.
@@ -33,23 +33,23 @@ The following technology-agnostic endpoints are available:
| Shows the conditions that were evaluated on configuration and auto-configuration classes and the reasons why they did or did not match.
| `configprops`
-| Displays a collated list of all `@ConfigurationProperties`.
+| Displays a collated list of all javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation].
Subject to xref:actuator/endpoints.adoc#actuator.endpoints.sanitization[sanitization].
| `env`
-| Exposes properties from Spring's `ConfigurableEnvironment`.
+| Exposes properties from Spring's javadoc:org.springframework.core.env.ConfigurableEnvironment[].
Subject to xref:actuator/endpoints.adoc#actuator.endpoints.sanitization[sanitization].
| `flyway`
| Shows any Flyway database migrations that have been applied.
- Requires one or more `Flyway` beans.
+ Requires one or more javadoc:org.flywaydb.core.Flyway[] beans.
| `health`
| Shows application health information.
| `httpexchanges`
| Displays HTTP exchange information (by default, the last 100 HTTP request-response exchanges).
- Requires an `HttpExchangeRepository` bean.
+ Requires an javadoc:org.springframework.boot.actuate.web.exchanges.HttpExchangeRepository[] bean.
| `info`
| Displays arbitrary application info.
@@ -63,13 +63,13 @@ Subject to xref:actuator/endpoints.adoc#actuator.endpoints.sanitization[sanitiza
| `liquibase`
| Shows any Liquibase database migrations that have been applied.
- Requires one or more `Liquibase` beans.
+ Requires one or more javadoc:{url-liquibase-javadoc}/liquibase.Liquibase[] beans.
| `metrics`
| Shows "`metrics`" information for the current application.
| `mappings`
-| Displays a collated list of all `@RequestMapping` paths.
+| Displays a collated list of all javadoc:org.springframework.web.bind.annotation.RequestMapping[format=annotation] paths.
|`quartz`
|Shows information about Quartz Scheduler jobs.
@@ -88,8 +88,8 @@ Subject to xref:actuator/endpoints.adoc#actuator.endpoints.sanitization[sanitiza
Disabled by default.
| `startup`
-| Shows the xref:features/spring-application.adoc#features.spring-application.startup-tracking[startup steps data] collected by the `ApplicationStartup`.
- Requires the `SpringApplication` to be configured with a `BufferingApplicationStartup`.
+| Shows the xref:features/spring-application.adoc#features.spring-application.startup-tracking[startup steps data] collected by the javadoc:org.springframework.core.metrics.ApplicationStartup[].
+ Requires the javadoc:org.springframework.boot.SpringApplication[] to be configured with a javadoc:org.springframework.boot.context.metrics.buffering.BufferingApplicationStartup[].
| `threaddump`
| Performs a thread dump.
@@ -208,7 +208,7 @@ NOTE: `*` has a special meaning in YAML, so be sure to add quotation marks if yo
NOTE: If your application is exposed publicly, we strongly recommend that you also xref:actuator/endpoints.adoc#actuator.endpoints.security[secure your endpoints].
-TIP: If you want to implement your own strategy for when endpoints are exposed, you can register an `EndpointFilter` bean.
+TIP: If you want to implement your own strategy for when endpoints are exposed, you can register an javadoc:org.springframework.boot.actuate.endpoint.EndpointFilter[] bean.
@@ -220,17 +220,17 @@ You can use the configprop:management.endpoints.web.exposure.include[] property
NOTE: Before setting the `management.endpoints.web.exposure.include`, ensure that the exposed actuators do not contain sensitive information, are secured by placing them behind a firewall, or are secured by something like Spring Security.
-If Spring Security is on the classpath and no other `SecurityFilterChain` bean is present, all actuators other than `/health` are secured by Spring Boot auto-configuration.
-If you define a custom `SecurityFilterChain` bean, Spring Boot auto-configuration backs off and lets you fully control the actuator access rules.
+If Spring Security is on the classpath and no other javadoc:org.springframework.security.web.SecurityFilterChain[] bean is present, all actuators other than `/health` are secured by Spring Boot auto-configuration.
+If you define a custom javadoc:org.springframework.security.web.SecurityFilterChain[] bean, Spring Boot auto-configuration backs off and lets you fully control the actuator access rules.
-If you wish to configure custom security for HTTP endpoints (for example, to allow only users with a certain role to access them), Spring Boot provides some convenient `RequestMatcher` objects that you can use in combination with Spring Security.
+If you wish to configure custom security for HTTP endpoints (for example, to allow only users with a certain role to access them), Spring Boot provides some convenient javadoc:org.springframework.security.web.util.matcher.RequestMatcher[] objects that you can use in combination with Spring Security.
A typical Spring Security configuration might look something like the following example:
include-code::typical/MySecurityConfiguration[]
The preceding example uses `EndpointRequest.toAnyEndpoint()` to match a request to any endpoint and then ensures that all have the `ENDPOINT_ADMIN` role.
-Several other matcher methods are also available on `EndpointRequest`.
+Several other matcher methods are also available on javadoc:org.springframework.boot.actuate.autoconfigure.security.servlet.EndpointRequest[].
See the xref:api:rest/actuator/index.adoc[API documentation] for details.
If you deploy applications behind a firewall, you may prefer that all your actuator endpoints can be accessed without requiring authentication.
@@ -250,7 +250,7 @@ Additionally, if Spring Security is present, you would need to add custom securi
include-code::exposeall/MySecurityConfiguration[]
NOTE: In both of the preceding examples, the configuration applies only to the actuator endpoints.
-Since Spring Boot's security configuration backs off completely in the presence of any `SecurityFilterChain` bean, you need to configure an additional `SecurityFilterChain` bean with rules that apply to the rest of the application.
+Since Spring Boot's security configuration backs off completely in the presence of any javadoc:org.springframework.security.web.SecurityFilterChain[] bean, you need to configure an additional javadoc:org.springframework.security.web.SecurityFilterChain[] bean with rules that apply to the rest of the application.
@@ -299,8 +299,8 @@ Values can only be viewed in an unsanitized form when:
The `show-values` property can be configured for sanitizable endpoints to one of the following values:
- `never` - values are always fully sanitized (replaced by `+******+`)
-- `always` - values are shown to all users (as long as no `SanitizingFunction` bean applies)
-- `when-authorized` - values are shown only to authorized users (as long as no `SanitizingFunction` bean applies)
+- `always` - values are shown to all users (as long as no javadoc:org.springframework.boot.actuate.endpoint.SanitizingFunction[] bean applies)
+- `when-authorized` - values are shown only to authorized users (as long as no javadoc:org.springframework.boot.actuate.endpoint.SanitizingFunction[] bean applies)
For HTTP endpoints, a user is considered to be authorized if they have authenticated and have the roles configured by the endpoint's roles property.
By default, any authenticated user is authorized.
@@ -372,7 +372,7 @@ TIP: See javadoc:org.springframework.boot.actuate.autoconfigure.endpoint.web.Cor
[[actuator.endpoints.implementing-custom]]
== Implementing Custom Endpoints
-If you add a `@Bean` annotated with `@Endpoint`, any methods annotated with `@ReadOperation`, `@WriteOperation`, or `@DeleteOperation` are automatically exposed over JMX and, in a web application, over HTTP as well.
+If you add a javadoc:org.springframework.context.annotation.Bean[format=annotation] annotated with javadoc:org.springframework.boot.actuate.endpoint.annotation.Endpoint[format=annotation], any methods annotated with javadoc:org.springframework.boot.actuate.endpoint.annotation.ReadOperation[format=annotation], javadoc:org.springframework.boot.actuate.endpoint.annotation.WriteOperation[format=annotation], or javadoc:org.springframework.boot.actuate.endpoint.annotation.DeleteOperation[format=annotation] are automatically exposed over JMX and, in a web application, over HTTP as well.
Endpoints can be exposed over HTTP by using Jersey, Spring MVC, or Spring WebFlux.
If both Jersey and Spring MVC are available, Spring MVC is used.
@@ -380,14 +380,14 @@ The following example exposes a read operation that returns a custom object:
include-code::MyEndpoint[tag=read]
-You can also write technology-specific endpoints by using `@JmxEndpoint` or `@WebEndpoint`.
+You can also write technology-specific endpoints by using javadoc:org.springframework.boot.actuate.endpoint.jmx.annotation.JmxEndpoint[format=annotation] or javadoc:org.springframework.boot.actuate.endpoint.web.annotation.WebEndpoint[format=annotation].
These endpoints are restricted to their respective technologies.
-For example, `@WebEndpoint` is exposed only over HTTP and not over JMX.
+For example, javadoc:org.springframework.boot.actuate.endpoint.web.annotation.WebEndpoint[format=annotation] is exposed only over HTTP and not over JMX.
-You can write technology-specific extensions by using `@EndpointWebExtension` and `@EndpointJmxExtension`.
+You can write technology-specific extensions by using javadoc:org.springframework.boot.actuate.endpoint.web.annotation.EndpointWebExtension[format=annotation] and javadoc:org.springframework.boot.actuate.endpoint.jmx.annotation.EndpointJmxExtension[format=annotation].
These annotations let you provide technology-specific operations to augment an existing endpoint.
-Finally, if you need access to web-framework-specific functionality, you can implement servlet or Spring `@Controller` and `@RestController` endpoints at the cost of them not being available over JMX or when using a different web framework.
+Finally, if you need access to web-framework-specific functionality, you can implement servlet or Spring javadoc:org.springframework.stereotype.Controller[format=annotation] and javadoc:org.springframework.web.bind.annotation.RestController[format=annotation] endpoints at the cost of them not being available over JMX or when using a different web framework.
@@ -398,7 +398,7 @@ Operations on an endpoint receive input through their parameters.
When exposed over the web, the values for these parameters are taken from the URL's query parameters and from the JSON request body.
When exposed over JMX, the parameters are mapped to the parameters of the MBean's operations.
Parameters are required by default.
-They can be made optional by annotating them with either `@javax.annotation.Nullable` or `@org.springframework.lang.Nullable`.
+They can be made optional by annotating them with either `@javax.annotation.Nullable` or javadoc:org.springframework.lang.Nullable[format=annotation].
You can map each root property in the JSON request body to a parameter of the endpoint.
Consider the following JSON request body:
@@ -416,7 +416,7 @@ You can use this to invoke a write operation that takes `String name` and `int c
include-code::../MyEndpoint[tag=write]
TIP: Because endpoints are technology agnostic, only simple types can be specified in the method signature.
-In particular, declaring a single parameter with a `CustomData` type that defines a `name` and `counter` properties is not supported.
+In particular, declaring a single parameter with a javadoc:liquibase.report.CustomData[] type that defines a `name` and `counter` properties is not supported.
NOTE: To let the input be mapped to the operation method's parameters, Java code that implements an endpoint should be compiled with `-parameters`, and Kotlin code that implements an endpoint should be compiled with `-java-parameters`.
This will happen automatically if you use Spring Boot's Gradle plugin or if you use Maven and `spring-boot-starter-parent`.
@@ -427,14 +427,14 @@ This will happen automatically if you use Spring Boot's Gradle plugin or if you
==== Input Type Conversion
The parameters passed to endpoint operation methods are, if necessary, automatically converted to the required type.
-Before calling an operation method, the input received over JMX or HTTP is converted to the required types by using an instance of `ApplicationConversionService` as well as any `Converter` or `GenericConverter` beans qualified with `@EndpointConverter`.
+Before calling an operation method, the input received over JMX or HTTP is converted to the required types by using an instance of javadoc:org.springframework.boot.convert.ApplicationConversionService[] as well as any javadoc:org.springframework.core.convert.converter.Converter[] or javadoc:org.springframework.core.convert.converter.GenericConverter[] beans qualified with javadoc:org.springframework.boot.actuate.endpoint.annotation.EndpointConverter[format=annotation].
[[actuator.endpoints.implementing-custom.web]]
=== Custom Web Endpoints
-Operations on an `@Endpoint`, `@WebEndpoint`, or `@EndpointWebExtension` are automatically exposed over HTTP using Jersey, Spring MVC, or Spring WebFlux.
+Operations on an javadoc:org.springframework.boot.actuate.endpoint.annotation.Endpoint[format=annotation], javadoc:org.springframework.boot.actuate.endpoint.web.annotation.WebEndpoint[format=annotation], or javadoc:org.springframework.boot.actuate.endpoint.web.annotation.EndpointWebExtension[format=annotation] are automatically exposed over HTTP using Jersey, Spring MVC, or Spring WebFlux.
If both Jersey and Spring MVC are available, Spring MVC is used.
@@ -453,7 +453,7 @@ The path of the predicate is determined by the ID of the endpoint and the base p
The default base path is `/actuator`.
For example, an endpoint with an ID of `sessions` uses `/actuator/sessions` as its path in the predicate.
-You can further customize the path by annotating one or more parameters of the operation method with `@Selector`.
+You can further customize the path by annotating one or more parameters of the operation method with javadoc:org.springframework.boot.actuate.endpoint.annotation.Selector[format=annotation].
Such a parameter is added to the path predicate as a path variable.
The variable's value is passed into the operation method when the endpoint operation is invoked.
If you want to capture all remaining path elements, you can add `@Selector(Match=ALL_REMAINING)` to the last parameter and make it a type that is conversion-compatible with a `String[]`.
@@ -469,13 +469,13 @@ The HTTP method of the predicate is determined by the operation type, as shown i
|===
| Operation | HTTP method
-| `@ReadOperation`
+| javadoc:org.springframework.boot.actuate.endpoint.annotation.ReadOperation[format=annotation]
| `GET`
-| `@WriteOperation`
+| javadoc:org.springframework.boot.actuate.endpoint.annotation.WriteOperation[format=annotation]
| `POST`
-| `@DeleteOperation`
+| javadoc:org.springframework.boot.actuate.endpoint.annotation.DeleteOperation[format=annotation]
| `DELETE`
|===
@@ -484,7 +484,7 @@ The HTTP method of the predicate is determined by the operation type, as shown i
[[actuator.endpoints.implementing-custom.web.consumes-predicates]]
==== Consumes
-For a `@WriteOperation` (HTTP `POST`) that uses the request body, the `consumes` clause of the predicate is `application/vnd.spring-boot.actuator.v2+json, application/json`.
+For a javadoc:org.springframework.boot.actuate.endpoint.annotation.WriteOperation[format=annotation] (HTTP `POST`) that uses the request body, the `consumes` clause of the predicate is `application/vnd.spring-boot.actuator.v2+json, application/json`.
For all other operations, the `consumes` clause is empty.
@@ -492,12 +492,12 @@ For all other operations, the `consumes` clause is empty.
[[actuator.endpoints.implementing-custom.web.produces-predicates]]
==== Produces
-The `produces` clause of the predicate can be determined by the `produces` attribute of the `@DeleteOperation`, `@ReadOperation`, and `@WriteOperation` annotations.
+The `produces` clause of the predicate can be determined by the `produces` attribute of the javadoc:org.springframework.boot.actuate.endpoint.annotation.DeleteOperation[format=annotation], javadoc:org.springframework.boot.actuate.endpoint.annotation.ReadOperation[format=annotation], and javadoc:org.springframework.boot.actuate.endpoint.annotation.WriteOperation[format=annotation] annotations.
The attribute is optional.
If it is not used, the `produces` clause is determined automatically.
-If the operation method returns `void` or `Void`, the `produces` clause is empty.
-If the operation method returns a `org.springframework.core.io.Resource`, the `produces` clause is `application/octet-stream`.
+If the operation method returns `void` or javadoc:java.lang.Void[], the `produces` clause is empty.
+If the operation method returns a javadoc:org.springframework.core.io.Resource[], the `produces` clause is `application/octet-stream`.
For all other operations, the `produces` clause is `application/vnd.spring-boot.actuator.v2+json, application/json`.
@@ -507,10 +507,10 @@ For all other operations, the `produces` clause is `application/vnd.spring-boot.
The default response status for an endpoint operation depends on the operation type (read, write, or delete) and what, if anything, the operation returns.
-If a `@ReadOperation` returns a value, the response status will be 200 (OK).
+If a javadoc:org.springframework.boot.actuate.endpoint.annotation.ReadOperation[format=annotation] returns a value, the response status will be 200 (OK).
If it does not return a value, the response status will be 404 (Not Found).
-If a `@WriteOperation` or `@DeleteOperation` returns a value, the response status will be 200 (OK).
+If a javadoc:org.springframework.boot.actuate.endpoint.annotation.WriteOperation[format=annotation] or javadoc:org.springframework.boot.actuate.endpoint.annotation.DeleteOperation[format=annotation] returns a value, the response status will be 200 (OK).
If it does not return a value, the response status will be 204 (No Content).
If an operation is invoked without a required parameter or with a parameter that cannot be converted to the required type, the operation method is not called, and the response status will be 400 (Bad Request).
@@ -521,7 +521,7 @@ If an operation is invoked without a required parameter or with a parameter that
==== Web Endpoint Range Requests
You can use an HTTP range request to request part of an HTTP resource.
-When using Spring MVC or Spring Web Flux, operations that return a `org.springframework.core.io.Resource` automatically support range requests.
+When using Spring MVC or Spring Web Flux, operations that return a javadoc:org.springframework.core.io.Resource[] automatically support range requests.
NOTE: Range requests are not supported when using Jersey.
@@ -530,8 +530,8 @@ NOTE: Range requests are not supported when using Jersey.
[[actuator.endpoints.implementing-custom.web.security]]
==== Web Endpoint Security
-An operation on a web endpoint or a web-specific endpoint extension can receive the current `java.security.Principal` or `org.springframework.boot.actuate.endpoint.SecurityContext` as a method parameter.
-The former is typically used in conjunction with `@Nullable` to provide different behavior for authenticated and unauthenticated users.
+An operation on a web endpoint or a web-specific endpoint extension can receive the current javadoc:java.security.Principal[] or javadoc:org.springframework.boot.actuate.endpoint.SecurityContext[] as a method parameter.
+The former is typically used in conjunction with either `@javax.annotation.Nullable` or javadoc:org.springframework.lang.Nullable[format=annotation] to provide different behavior for authenticated and unauthenticated users.
The latter is typically used to perform authorization checks by using its `isUserInRole(String)` method.
@@ -565,26 +565,26 @@ You can configure the roles by using the configprop:management.endpoint.health.r
NOTE: If you have secured your application and wish to use `always`, your security configuration must permit access to the health endpoint for both authenticated and unauthenticated users.
-Health information is collected from the content of a javadoc:org.springframework.boot.actuate.health.HealthContributorRegistry[] (by default, all javadoc:org.springframework.boot.actuate.health.HealthContributor[] instances defined in your `ApplicationContext`).
-Spring Boot includes a number of auto-configured `HealthContributor` beans, and you can also write your own.
+Health information is collected from the content of a javadoc:org.springframework.boot.actuate.health.HealthContributorRegistry[] (by default, all javadoc:org.springframework.boot.actuate.health.HealthContributor[] instances defined in your javadoc:org.springframework.context.ApplicationContext[]).
+Spring Boot includes a number of auto-configured javadoc:org.springframework.boot.actuate.health.HealthContributor[] beans, and you can also write your own.
-A `HealthContributor` can be either a `HealthIndicator` or a `CompositeHealthContributor`.
-A `HealthIndicator` provides actual health information, including a `Status`.
-A `CompositeHealthContributor` provides a composite of other `HealthContributor` instances.
+A javadoc:org.springframework.boot.actuate.health.HealthContributor[] can be either a javadoc:org.springframework.boot.actuate.health.HealthIndicator[] or a javadoc:org.springframework.boot.actuate.health.CompositeHealthContributor[].
+A javadoc:org.springframework.boot.actuate.health.HealthIndicator[] provides actual health information, including a javadoc:org.springframework.boot.actuate.health.Status[].
+A javadoc:org.springframework.boot.actuate.health.CompositeHealthContributor[] provides a composite of other javadoc:org.springframework.boot.actuate.health.HealthContributor[] instances.
Taken together, contributors form a tree structure to represent the overall system health.
-By default, the final system health is derived by a `StatusAggregator`, which sorts the statuses from each `HealthIndicator` based on an ordered list of statuses.
+By default, the final system health is derived by a javadoc:org.springframework.boot.actuate.health.StatusAggregator[], which sorts the statuses from each javadoc:org.springframework.boot.actuate.health.HealthIndicator[] based on an ordered list of statuses.
The first status in the sorted list is used as the overall health status.
-If no `HealthIndicator` returns a status that is known to the `StatusAggregator`, an `UNKNOWN` status is used.
+If no javadoc:org.springframework.boot.actuate.health.HealthIndicator[] returns a status that is known to the javadoc:org.springframework.boot.actuate.health.StatusAggregator[], an `UNKNOWN` status is used.
-TIP: You can use the `HealthContributorRegistry` to register and unregister health indicators at runtime.
+TIP: You can use the javadoc:org.springframework.boot.actuate.health.HealthContributorRegistry[] to register and unregister health indicators at runtime.
[[actuator.endpoints.health.auto-configured-health-indicators]]
=== Auto-configured HealthIndicators
-When appropriate, Spring Boot auto-configures the `HealthIndicator` beans listed in the following table.
+When appropriate, Spring Boot auto-configures the javadoc:org.springframework.boot.actuate.health.HealthIndicator[] beans listed in the following table.
You can also enable or disable selected indicators by configuring `management.health.key.enabled`,
with the `key` listed in the following table:
@@ -602,7 +602,7 @@ with the `key` listed in the following table:
| `db`
| javadoc:org.springframework.boot.actuate.jdbc.DataSourceHealthIndicator[]
-| Checks that a connection to `DataSource` can be obtained.
+| Checks that a connection to javadoc:javax.sql.DataSource[] can be obtained.
| `diskspace`
| javadoc:org.springframework.boot.actuate.system.DiskSpaceHealthIndicator[]
@@ -655,7 +655,7 @@ with the `key` listed in the following table:
TIP: You can disable them all by setting the configprop:management.health.defaults.enabled[] property.
-Additional `HealthIndicator` beans are available, but are not enabled by default:
+Additional javadoc:org.springframework.boot.actuate.health.HealthIndicator[] beans are available, but are not enabled by default:
[cols="3,4,6"]
|===
@@ -676,23 +676,23 @@ Additional `HealthIndicator` beans are available, but are not enabled by default
=== Writing Custom HealthIndicators
To provide custom health information, you can register Spring beans that implement the javadoc:org.springframework.boot.actuate.health.HealthIndicator[] interface.
-You need to provide an implementation of the `health()` method and return a `Health` response.
-The `Health` response should include a status and can optionally include additional details to be displayed.
-The following code shows a sample `HealthIndicator` implementation:
+You need to provide an implementation of the `health()` method and return a javadoc:org.springframework.boot.actuate.health.Health[] response.
+The javadoc:org.springframework.boot.actuate.health.Health[] response should include a status and can optionally include additional details to be displayed.
+The following code shows a sample javadoc:org.springframework.boot.actuate.health.HealthIndicator[] implementation:
include-code::MyHealthIndicator[]
-NOTE: The identifier for a given `HealthIndicator` is the name of the bean without the `HealthIndicator` suffix, if it exists.
+NOTE: The identifier for a given javadoc:org.springframework.boot.actuate.health.HealthIndicator[] is the name of the bean without the javadoc:org.springframework.boot.actuate.health.HealthIndicator[] suffix, if it exists.
In the preceding example, the health information is available in an entry named `my`.
TIP: Health indicators are usually called over HTTP and need to respond before any connection timeouts.
Spring Boot will log a warning message for any health indicator that takes longer than 10 seconds to respond.
If you want to configure this threshold, you can use the configprop:management.endpoint.health.logging.slow-indicator-threshold[] property.
-In addition to Spring Boot's predefined javadoc:org.springframework.boot.actuate.health.Status[] types, `Health` can return a custom `Status` that represents a new system state.
+In addition to Spring Boot's predefined javadoc:org.springframework.boot.actuate.health.Status[] types, javadoc:org.springframework.boot.actuate.health.Health[] can return a custom javadoc:org.springframework.boot.actuate.health.Status[] that represents a new system state.
In such cases, you also need to provide a custom implementation of the javadoc:org.springframework.boot.actuate.health.StatusAggregator[] interface, or you must configure the default implementation by using the configprop:management.endpoint.health.status.order[] configuration property.
-For example, assume a new `Status` with a code of `FATAL` is being used in one of your `HealthIndicator` implementations.
+For example, assume a new javadoc:org.springframework.boot.actuate.health.Status[] with a code of `FATAL` is being used in one of your javadoc:org.springframework.boot.actuate.health.HealthIndicator[] implementations.
To configure the severity order, add the following property to your application properties:
[configprops,yaml]
@@ -724,7 +724,7 @@ management:
out-of-service: 503
----
-TIP: If you need more control, you can define your own `HttpCodeStatusMapper` bean.
+TIP: If you need more control, you can define your own javadoc:org.springframework.boot.actuate.health.HttpCodeStatusMapper[] bean.
The following table shows the default status mappings for the built-in statuses:
@@ -750,26 +750,26 @@ The following table shows the default status mappings for the built-in statuses:
[[actuator.endpoints.health.reactive-health-indicators]]
=== Reactive Health Indicators
-For reactive applications, such as those that use Spring WebFlux, `ReactiveHealthContributor` provides a non-blocking contract for getting application health.
-Similar to a traditional `HealthContributor`, health information is collected from the content of a javadoc:org.springframework.boot.actuate.health.ReactiveHealthContributorRegistry[] (by default, all javadoc:org.springframework.boot.actuate.health.HealthContributor[] and javadoc:org.springframework.boot.actuate.health.ReactiveHealthContributor[] instances defined in your `ApplicationContext`).
-Regular `HealthContributor` instances that do not check against a reactive API are executed on the elastic scheduler.
+For reactive applications, such as those that use Spring WebFlux, javadoc:org.springframework.boot.actuate.health.ReactiveHealthContributor[] provides a non-blocking contract for getting application health.
+Similar to a traditional javadoc:org.springframework.boot.actuate.health.HealthContributor[], health information is collected from the content of a javadoc:org.springframework.boot.actuate.health.ReactiveHealthContributorRegistry[] (by default, all javadoc:org.springframework.boot.actuate.health.HealthContributor[] and javadoc:org.springframework.boot.actuate.health.ReactiveHealthContributor[] instances defined in your javadoc:org.springframework.context.ApplicationContext[]).
+Regular javadoc:org.springframework.boot.actuate.health.HealthContributor[] instances that do not check against a reactive API are executed on the elastic scheduler.
-TIP: In a reactive application, you should use the `ReactiveHealthContributorRegistry` to register and unregister health indicators at runtime.
-If you need to register a regular `HealthContributor`, you should wrap it with `ReactiveHealthContributor#adapt`.
+TIP: In a reactive application, you should use the javadoc:org.springframework.boot.actuate.health.ReactiveHealthContributorRegistry[] to register and unregister health indicators at runtime.
+If you need to register a regular javadoc:org.springframework.boot.actuate.health.HealthContributor[], you should wrap it with `ReactiveHealthContributor#adapt`.
To provide custom health information from a reactive API, you can register Spring beans that implement the javadoc:org.springframework.boot.actuate.health.ReactiveHealthIndicator[] interface.
-The following code shows a sample `ReactiveHealthIndicator` implementation:
+The following code shows a sample javadoc:org.springframework.boot.actuate.health.ReactiveHealthIndicator[] implementation:
include-code::MyReactiveHealthIndicator[]
-TIP: To handle the error automatically, consider extending from `AbstractReactiveHealthIndicator`.
+TIP: To handle the error automatically, consider extending from javadoc:org.springframework.boot.actuate.health.AbstractReactiveHealthIndicator[].
[[actuator.endpoints.health.auto-configured-reactive-health-indicators]]
=== Auto-configured ReactiveHealthIndicators
-When appropriate, Spring Boot auto-configures the following `ReactiveHealthIndicator` beans:
+When appropriate, Spring Boot auto-configures the following javadoc:org.springframework.boot.actuate.health.ReactiveHealthIndicator[] beans:
[cols="2,4,6"]
|===
@@ -801,7 +801,7 @@ When appropriate, Spring Boot auto-configures the following `ReactiveHealthIndic
|===
TIP: If necessary, reactive indicators replace the regular ones.
-Also, any `HealthIndicator` that is not handled explicitly is wrapped automatically.
+Also, any javadoc:org.springframework.boot.actuate.health.HealthIndicator[] that is not handled explicitly is wrapped automatically.
@@ -840,7 +840,7 @@ management:
By default, startup will fail if a health group includes or excludes a health indicator that does not exist.
To disable this behavior set configprop:management.endpoint.health.validate-group-membership[] to `false`.
-By default, groups inherit the same `StatusAggregator` and `HttpCodeStatusMapper` settings as the system health.
+By default, groups inherit the same javadoc:org.springframework.boot.actuate.health.StatusAggregator[] and javadoc:org.springframework.boot.actuate.health.HttpCodeStatusMapper[] settings as the system health.
However, you can also define these on a per-group basis.
You can also override the `show-details` and `roles` properties if required:
@@ -860,10 +860,10 @@ management:
out-of-service: 500
----
-TIP: You can use `@Qualifier("groupname")` if you need to register custom `StatusAggregator` or `HttpCodeStatusMapper` beans for use with the group.
+TIP: You can use `@Qualifier("groupname")` if you need to register custom javadoc:org.springframework.boot.actuate.health.StatusAggregator[] or javadoc:org.springframework.boot.actuate.health.HttpCodeStatusMapper[] beans for use with the group.
-A health group can also include/exclude a `CompositeHealthContributor`.
-You can also include/exclude only a certain component of a `CompositeHealthContributor`.
+A health group can also include/exclude a javadoc:org.springframework.boot.actuate.health.CompositeHealthContributor[].
+You can also include/exclude only a certain component of a javadoc:org.springframework.boot.actuate.health.CompositeHealthContributor[].
This can be done using the fully qualified name of the component as follows:
[source,properties]
@@ -872,8 +872,8 @@ management.endpoint.health.group.custom.include="test/primary"
management.endpoint.health.group.custom.exclude="test/primary/b"
----
-In the example above, the `custom` group will include the `HealthContributor` with the name `primary` which is a component of the composite `test`.
-Here, `primary` itself is a composite and the `HealthContributor` with the name `b` will be excluded from the `custom` group.
+In the example above, the `custom` group will include the javadoc:org.springframework.boot.actuate.health.HealthContributor[] with the name `primary` which is a component of the composite `test`.
+Here, `primary` itself is a composite and the javadoc:org.springframework.boot.actuate.health.HealthContributor[] with the name `b` will be excluded from the `custom` group.
Health groups can be made available at an additional path on either the main or management port.
@@ -895,7 +895,7 @@ The path must be a single path segment.
[[actuator.endpoints.health.datasource]]
=== DataSource Health
-The `DataSource` health indicator shows the health of both standard data sources and routing data source beans.
+The javadoc:javax.sql.DataSource[] health indicator shows the health of both standard data sources and routing data source beans.
The health of a routing data source includes the health of each of its target data sources.
In the health endpoint's response, each of a routing data source's targets is named by using its routing key.
If you prefer not to include routing data sources in the indicator's output, set configprop:management.health.db.ignore-routing-data-sources[] to `true`.
@@ -909,7 +909,7 @@ Applications deployed on Kubernetes can provide information about their internal
Depending on https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/[your Kubernetes configuration], the kubelet calls those probes and reacts to the result.
By default, Spring Boot manages your xref:features/spring-application.adoc#features.spring-application.application-availability[Application Availability] state.
-If deployed in a Kubernetes environment, actuator gathers the "`Liveness`" and "`Readiness`" information from the `ApplicationAvailability` interface and uses that information in dedicated xref:actuator/endpoints.adoc#actuator.endpoints.health.auto-configured-health-indicators[health indicators]: `LivenessStateHealthIndicator` and `ReadinessStateHealthIndicator`.
+If deployed in a Kubernetes environment, actuator gathers the "`Liveness`" and "`Readiness`" information from the javadoc:org.springframework.boot.availability.ApplicationAvailability[] interface and uses that information in dedicated xref:actuator/endpoints.adoc#actuator.endpoints.health.auto-configured-health-indicators[health indicators]: javadoc:org.springframework.boot.actuate.availability.LivenessStateHealthIndicator[] and javadoc:org.springframework.boot.actuate.availability.ReadinessStateHealthIndicator[].
These indicators are shown on the global health endpoint (`"/actuator/health"`).
They are also exposed as separate HTTP Probes by using xref:actuator/endpoints.adoc#actuator.endpoints.health.groups[health groups]: `"/actuator/health/liveness"` and `"/actuator/health/readiness"`.
@@ -1003,14 +1003,14 @@ Also, if an application uses Kubernetes https://kubernetes.io/docs/tasks/run-app
=== Application Lifecycle and Probe States
An important aspect of the Kubernetes Probes support is its consistency with the application lifecycle.
-There is a significant difference between the `AvailabilityState` (which is the in-memory, internal state of the application)
+There is a significant difference between the javadoc:org.springframework.boot.availability.AvailabilityState[] (which is the in-memory, internal state of the application)
and the actual probe (which exposes that state).
Depending on the phase of application lifecycle, the probe might not be available.
Spring Boot publishes xref:features/spring-application.adoc#features.spring-application.application-events-and-listeners[application events during startup and shutdown],
-and probes can listen to such events and expose the `AvailabilityState` information.
+and probes can listen to such events and expose the javadoc:org.springframework.boot.availability.AvailabilityState[] information.
-The following tables show the `AvailabilityState` and the state of HTTP connectors at different stages.
+The following tables show the javadoc:org.springframework.boot.availability.AvailabilityState[] and the state of HTTP connectors at different stages.
When a Spring Boot application starts:
@@ -1069,15 +1069,15 @@ TIP: See xref:how-to:deployment/cloud.adoc#howto.deployment.cloud.kubernetes.con
[[actuator.endpoints.info]]
== Application Information
-Application information exposes various information collected from all javadoc:org.springframework.boot.actuate.info.InfoContributor[] beans defined in your `ApplicationContext`.
-Spring Boot includes a number of auto-configured `InfoContributor` beans, and you can write your own.
+Application information exposes various information collected from all javadoc:org.springframework.boot.actuate.info.InfoContributor[] beans defined in your javadoc:org.springframework.context.ApplicationContext[].
+Spring Boot includes a number of auto-configured javadoc:org.springframework.boot.actuate.info.InfoContributor[] beans, and you can write your own.
[[actuator.endpoints.info.auto-configured-info-contributors]]
=== Auto-configured InfoContributors
-When appropriate, Spring auto-configures the following `InfoContributor` beans:
+When appropriate, Spring auto-configures the following javadoc:org.springframework.boot.actuate.info.InfoContributor[] beans:
[cols="1,4,8,4"]
|===
@@ -1090,7 +1090,7 @@ When appropriate, Spring auto-configures the following `InfoContributor` beans:
| `env`
| javadoc:org.springframework.boot.actuate.info.EnvironmentInfoContributor[]
-| Exposes any property from the `Environment` whose name starts with `info.`.
+| Exposes any property from the javadoc:org.springframework.core.env.Environment[] whose name starts with `info.`.
| None.
| `git`
@@ -1131,7 +1131,7 @@ Alternatively, to disable every contributor that is usually enabled by default,
=== Custom Application Information
When the `env` contributor is enabled, you can customize the data exposed by the `info` endpoint by setting `+info.*+` Spring properties.
-All `Environment` properties under the `info` key are automatically exposed.
+All javadoc:org.springframework.core.env.Environment[] properties under the `info` key are automatically exposed.
For example, you could add the following settings to your `application.properties` file:
[configprops,yaml]
@@ -1167,9 +1167,9 @@ info:
=== Git Commit Information
Another useful feature of the `info` endpoint is its ability to publish information about the state of your `git` source code repository when the project was built.
-If a `GitProperties` bean is available, you can use the `info` endpoint to expose these properties.
+If a javadoc:org.springframework.boot.info.GitProperties[] bean is available, you can use the `info` endpoint to expose these properties.
-TIP: A `GitProperties` bean is auto-configured if a `git.properties` file is available at the root of the classpath.
+TIP: A javadoc:org.springframework.boot.info.GitProperties[] bean is auto-configured if a `git.properties` file is available at the root of the classpath.
See xref:how-to:build.adoc#howto.build.generate-git-info[] for more detail.
By default, the endpoint exposes `git.branch`, `git.commit.id`, and `git.commit.time` properties, if present.
@@ -1199,7 +1199,7 @@ management:
[[actuator.endpoints.info.build-information]]
=== Build Information
-If a `BuildProperties` bean is available, the `info` endpoint can also publish information about your build.
+If a javadoc:org.springframework.boot.info.BuildProperties[] bean is available, the `info` endpoint can also publish information about your build.
This happens if a `META-INF/build-info.properties` file is available in the classpath.
TIP: The Maven and Gradle plugins can both generate that file.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/http-exchanges.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/http-exchanges.adoc
index 06b12f1e96..641ed6484e 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/http-exchanges.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/http-exchanges.adoc
@@ -1,13 +1,13 @@
[[actuator.http-exchanges]]
= Recording HTTP Exchanges
-You can enable recording of HTTP exchanges by providing a bean of type `HttpExchangeRepository` in your application's configuration.
-For convenience, Spring Boot offers `InMemoryHttpExchangeRepository`, which, by default, stores the last 100 request-response exchanges.
-`InMemoryHttpExchangeRepository` is limited compared to tracing solutions, and we recommend using it only for development environments.
+You can enable recording of HTTP exchanges by providing a bean of type javadoc:org.springframework.boot.actuate.web.exchanges.HttpExchangeRepository[] in your application's configuration.
+For convenience, Spring Boot offers javadoc:org.springframework.boot.actuate.web.exchanges.InMemoryHttpExchangeRepository[], which, by default, stores the last 100 request-response exchanges.
+javadoc:org.springframework.boot.actuate.web.exchanges.InMemoryHttpExchangeRepository[] is limited compared to tracing solutions, and we recommend using it only for development environments.
For production environments, we recommend using a production-ready tracing or observability solution, such as Zipkin or OpenTelemetry.
-Alternatively, you can create your own `HttpExchangeRepository`.
+Alternatively, you can create your own javadoc:org.springframework.boot.actuate.web.exchanges.HttpExchangeRepository[].
-You can use the `httpexchanges` endpoint to obtain information about the request-response exchanges that are stored in the `HttpExchangeRepository`.
+You can use the `httpexchanges` endpoint to obtain information about the request-response exchanges that are stored in the javadoc:org.springframework.boot.actuate.web.exchanges.HttpExchangeRepository[].
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/jmx.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/jmx.adoc
index 4751c26dd0..0672e88747 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/jmx.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/jmx.adoc
@@ -4,11 +4,11 @@
Java Management Extensions (JMX) provide a standard mechanism to monitor and manage applications.
By default, this feature is not enabled.
You can turn it on by setting the configprop:spring.jmx.enabled[] configuration property to `true`.
-Spring Boot exposes the most suitable `MBeanServer` as a bean with an ID of `mbeanServer`.
-Any of your beans that are annotated with Spring JMX annotations (`@ManagedResource`, `@ManagedAttribute`, or `@ManagedOperation`) are exposed to it.
+Spring Boot exposes the most suitable javadoc:javax.management.MBeanServer[] as a bean with an ID of `mbeanServer`.
+Any of your beans that are annotated with Spring JMX annotations (`@org.springframework.jmx.export.annotation.ManagedResource`, javadoc:org.springframework.jmx.export.annotation.ManagedAttribute[format=annotation], or javadoc:org.springframework.jmx.export.annotation.ManagedOperation[format=annotation]) are exposed to it.
-If your platform provides a standard `MBeanServer`, Spring Boot uses that and defaults to the VM `MBeanServer`, if necessary.
-If all that fails, a new `MBeanServer` is created.
+If your platform provides a standard javadoc:javax.management.MBeanServer[], Spring Boot uses that and defaults to the VM javadoc:javax.management.MBeanServer[], if necessary.
+If all that fails, a new javadoc:javax.management.MBeanServer[] is created.
NOTE: `spring.jmx.enabled` affects only the management beans provided by Spring.
Enabling management beans provided by other libraries (for example {url-log4j2-docs}/jmx.html[Log4j2] or {url-quartz-javadoc}/constant-values.html#org.quartz.impl.StdSchedulerFactory.PROP_SCHED_JMX_EXPORT[Quartz]) is independent.
@@ -16,7 +16,7 @@ Enabling management beans provided by other libraries (for example {url-log4j2-d
See the {code-spring-boot-autoconfigure-src}/jmx/JmxAutoConfiguration.java[`JmxAutoConfiguration`] class for more details.
By default, Spring Boot also exposes management endpoints as JMX MBeans under the `org.springframework.boot` domain.
-To take full control over endpoint registration in the JMX domain, consider registering your own `EndpointObjectNameFactory` implementation.
+To take full control over endpoint registration in the JMX domain, consider registering your own javadoc:org.springframework.boot.actuate.endpoint.jmx.EndpointObjectNameFactory[] implementation.
@@ -26,7 +26,7 @@ To take full control over endpoint registration in the JMX domain, consider regi
The name of the MBean is usually generated from the `id` of the endpoint.
For example, the `health` endpoint is exposed as `org.springframework.boot:type=Endpoint,name=Health`.
-If your application contains more than one Spring `ApplicationContext`, you may find that names clash.
+If your application contains more than one Spring javadoc:org.springframework.context.ApplicationContext[], you may find that names clash.
To solve this problem, you can set the configprop:spring.jmx.unique-names[] property to `true` so that MBean names are always unique.
You can also customize the JMX domain under which endpoints are exposed.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/metrics.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/metrics.adoc
index 0e887cb538..df056a18c6 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/metrics.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/metrics.adoc
@@ -30,7 +30,7 @@ TIP: To learn more about Micrometer's capabilities, see its {url-micrometer-docs
[[actuator.metrics.getting-started]]
== Getting Started
-Spring Boot auto-configures a composite `MeterRegistry` and adds a registry to the composite for each of the supported implementations that it finds on the classpath.
+Spring Boot auto-configures a composite javadoc:io.micrometer.core.instrument.MeterRegistry[] and adds a registry to the composite for each of the supported implementations that it finds on the classpath.
Having a dependency on `micrometer-registry-\{system}` in your runtime classpath is enough for Spring Boot to configure the registry.
Most registries share common features.
@@ -57,7 +57,7 @@ management:
enabled: false
----
-Spring Boot also adds any auto-configured registries to the global static composite registry on the `Metrics` class, unless you explicitly tell it not to:
+Spring Boot also adds any auto-configured registries to the global static composite registry on the javadoc:io.micrometer.core.instrument.Metrics[] class, unless you explicitly tell it not to:
[configprops,yaml]
----
@@ -66,7 +66,7 @@ management:
use-global-registry: false
----
-You can register any number of `MeterRegistryCustomizer` beans to further configure the registry, such as applying common tags, before any meters are registered with the registry:
+You can register any number of javadoc:org.springframework.boot.actuate.autoconfigure.metrics.MeterRegistryCustomizer[] beans to further configure the registry, such as applying common tags, before any meters are registered with the registry:
include-code::commontags/MyMeterRegistryConfiguration[]
@@ -359,12 +359,12 @@ management:
port: 9004
----
-Micrometer provides a default `HierarchicalNameMapper` that governs how a dimensional meter ID is {url-micrometer-docs-implementations}/graphite#_hierarchical_name_mapping[mapped to flat hierarchical names].
+Micrometer provides a default javadoc:io.micrometer.core.instrument.util.HierarchicalNameMapper[] that governs how a dimensional meter ID is {url-micrometer-docs-implementations}/graphite#_hierarchical_name_mapping[mapped to flat hierarchical names].
[TIP]
====
-To take control over this behavior, define your `GraphiteMeterRegistry` and supply your own `HierarchicalNameMapper`.
-An auto-configured `GraphiteConfig` and `Clock` beans are provided unless you define your own:
+To take control over this behavior, define your javadoc:io.micrometer.graphite.GraphiteMeterRegistry[] and supply your own javadoc:io.micrometer.core.instrument.util.HierarchicalNameMapper[].
+Auto-configured javadoc:io.micrometer.graphite.GraphiteConfig[] and javadoc:io.micrometer.core.instrument.Clock[] beans are provided unless you define your own:
include-code::MyGraphiteConfiguration[]
====
@@ -435,12 +435,12 @@ management:
domain: "com.example.app.metrics"
----
-Micrometer provides a default `HierarchicalNameMapper` that governs how a dimensional meter ID is {url-micrometer-docs-implementations}/jmx#_hierarchical_name_mapping[mapped to flat hierarchical names].
+Micrometer provides a default javadoc:io.micrometer.core.instrument.util.HierarchicalNameMapper[] that governs how a dimensional meter ID is {url-micrometer-docs-implementations}/jmx#_hierarchical_name_mapping[mapped to flat hierarchical names].
[TIP]
====
-To take control over this behavior, define your `JmxMeterRegistry` and supply your own `HierarchicalNameMapper`.
-An auto-configured `JmxConfig` and `Clock` beans are provided unless you define your own:
+To take control over this behavior, define your javadoc:io.micrometer.jmx.JmxMeterRegistry[] and supply your own javadoc:io.micrometer.core.instrument.util.HierarchicalNameMapper[].
+Auto-configured javadoc:io.micrometer.jmx.JmxConfig[] and javadoc:io.micrometer.core.instrument.Clock[] beans are provided unless you define your own:
include-code::MyJmxConfiguration[]
====
@@ -502,7 +502,7 @@ management:
client-provider-type: "insights-agent"
----
-Finally, you can take full control by defining your own `NewRelicClientProvider` bean.
+Finally, you can take full control by defining your own javadoc:io.micrometer.newrelic.NewRelicClientProvider[] bean.
@@ -543,8 +543,8 @@ scrape_configs:
----
https://prometheus.io/docs/prometheus/latest/feature_flags/#exemplars-storage[Prometheus Exemplars] are also supported.
-To enable this feature, a `SpanContext` bean should be present.
-If you're using the deprecated Prometheus simpleclient support and want to enable that feature, a `SpanContextSupplier` bean should be present.
+To enable this feature, a javadoc:io.prometheus.metrics.tracer.common.SpanContext[] bean should be present.
+If you're using the deprecated Prometheus simpleclient support and want to enable that feature, a javadoc:io.prometheus.client.exemplars.tracer.common.SpanContextSupplier[] bean should be present.
If you use {url-micrometer-tracing-docs}[Micrometer Tracing], this will be auto-configured for you, but you can always create your own if you want.
Please check the https://prometheus.io/docs/prometheus/latest/feature_flags/#exemplars-storage[Prometheus Docs], since this feature needs to be explicitly enabled on Prometheus' side, and it is only supported using the https://github.com/OpenObservability/OpenMetrics/blob/v1.0.0/specification/OpenMetrics.md#exemplars[OpenMetrics] format.
@@ -563,11 +563,11 @@ To enable Prometheus Pushgateway support, add the following dependency to your p
----
-When the Prometheus Pushgateway dependency is present on the classpath and the configprop:management.prometheus.metrics.export.pushgateway.enabled[] property is set to `true`, a `PrometheusPushGatewayManager` bean is auto-configured.
+When the Prometheus Pushgateway dependency is present on the classpath and the configprop:management.prometheus.metrics.export.pushgateway.enabled[] property is set to `true`, a javadoc:org.springframework.boot.actuate.metrics.export.prometheus.PrometheusPushGatewayManager[] bean is auto-configured.
This manages the pushing of metrics to a Prometheus Pushgateway.
-You can tune the `PrometheusPushGatewayManager` by using properties under `management.prometheus.metrics.export.pushgateway`.
-For advanced configuration, you can also provide your own `PrometheusPushGatewayManager` bean.
+You can tune the javadoc:org.springframework.boot.actuate.metrics.export.prometheus.PrometheusPushGatewayManager[] by using properties under `management.prometheus.metrics.export.pushgateway`.
+For advanced configuration, you can also provide your own javadoc:org.springframework.boot.actuate.metrics.export.prometheus.PrometheusPushGatewayManager[] bean.
@@ -778,7 +778,7 @@ The details are published under the `log4j2.events.` or `logback.events.` meter
[[actuator.metrics.supported.tasks]]
=== Task Execution and Scheduling Metrics
-Auto-configuration enables the instrumentation of all available `ThreadPoolTaskExecutor` and `ThreadPoolTaskScheduler` beans, as long as the underling `ThreadPoolExecutor` is available.
+Auto-configuration enables the instrumentation of all available javadoc:org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor[] and javadoc:org.springframework.scheduling.concurrent.ThreadPoolTaskScheduler[] beans, as long as the underling javadoc:java.util.concurrent.ThreadPoolExecutor[] is available.
Metrics are tagged by the name of the executor, which is derived from the bean name.
@@ -786,7 +786,7 @@ Metrics are tagged by the name of the executor, which is derived from the bean n
[[actuator.metrics.supported.jms]]
=== JMS Metrics
-Auto-configuration enables the instrumentation of all available `JmsTemplate` beans and `@JmsListener` annotated methods.
+Auto-configuration enables the instrumentation of all available javadoc:org.springframework.jms.core.JmsTemplate[] beans and javadoc:org.springframework.jms.annotation.JmsListener[format=annotation] annotated methods.
This will produce `"jms.message.publish"` and `"jms.message.process"` metrics respectively.
See the {url-spring-framework-docs}/integration/observability.html#observability.jms[Spring Framework reference documentation for more information on produced observations].
@@ -801,15 +801,15 @@ You can customize the name by setting the configprop:management.observations.htt
See the {url-spring-framework-docs}/integration/observability.html#observability.http-server.servlet[Spring Framework reference documentation for more information on produced observations].
-To add to the default tags, provide a `@Bean` that extends `DefaultServerRequestObservationConvention` from the `org.springframework.http.server.observation` package.
-To replace the default tags, provide a `@Bean` that implements `ServerRequestObservationConvention`.
+To add to the default tags, provide a javadoc:org.springframework.context.annotation.Bean[format=annotation] that extends javadoc:org.springframework.http.server.observation.DefaultServerRequestObservationConvention[] from the `org.springframework.http.server.observation` package.
+To replace the default tags, provide a javadoc:org.springframework.context.annotation.Bean[format=annotation] that implements javadoc:org.springframework.http.server.observation.ServerRequestObservationConvention[].
TIP: In some cases, exceptions handled in web controllers are not recorded as request metrics tags.
Applications can opt in and record exceptions by xref:web/servlet.adoc#web.servlet.spring-mvc.error-handling[setting handled exceptions as request attributes].
By default, all requests are handled.
-To customize the filter, provide a `@Bean` that implements `FilterRegistrationBean`.
+To customize the filter, provide a javadoc:org.springframework.context.annotation.Bean[format=annotation] that implements `FilterRegistrationBean`.
@@ -822,8 +822,8 @@ You can customize the name by setting the configprop:management.observations.htt
See the {url-spring-framework-docs}/integration/observability.html#observability.http-server.reactive[Spring Framework reference documentation for more information on produced observations].
-To add to the default tags, provide a `@Bean` that extends `DefaultServerRequestObservationConvention` from the `org.springframework.http.server.reactive.observation` package.
-To replace the default tags, provide a `@Bean` that implements `ServerRequestObservationConvention`.
+To add to the default tags, provide a javadoc:org.springframework.context.annotation.Bean[format=annotation] that extends javadoc:org.springframework.http.server.reactive.observation.DefaultServerRequestObservationConvention[] from the `org.springframework.http.server.reactive.observation` package.
+To replace the default tags, provide a javadoc:org.springframework.context.annotation.Bean[format=annotation] that implements javadoc:org.springframework.http.server.reactive.observation.ServerRequestObservationConvention[].
TIP: In some cases, exceptions handled in controllers and handler functions are not recorded as request metrics tags.
Applications can opt in and record exceptions by xref:web/reactive.adoc#web.reactive.webflux.error-handling[setting handled exceptions as request attributes].
@@ -859,36 +859,36 @@ By default, Jersey server metrics are tagged with the following information:
| The request's URI template prior to variable substitution, if possible (for example, `/api/person/\{id}`)
|===
-To customize the tags, provide a `@Bean` that implements `JerseyObservationConvention`.
+To customize the tags, provide a javadoc:org.springframework.context.annotation.Bean[format=annotation] that implements javadoc:io.micrometer.core.instrument.binder.jersey.server.JerseyObservationConvention[].
[[actuator.metrics.supported.http-clients]]
=== HTTP Client Metrics
-Spring Boot Actuator manages the instrumentation of `RestTemplate`, `WebClient` and `RestClient`.
+Spring Boot Actuator manages the instrumentation of javadoc:org.springframework.web.client.RestTemplate[], javadoc:org.springframework.web.reactive.function.client.WebClient[] and javadoc:org.springframework.web.client.RestClient[].
For that, you have to inject the auto-configured builder and use it to create instances:
-* `RestTemplateBuilder` for `RestTemplate`
-* `WebClient.Builder` for `WebClient`
-* `RestClient.Builder` for `RestClient`
+* javadoc:org.springframework.boot.web.client.RestTemplateBuilder[] for javadoc:org.springframework.web.client.RestTemplate[]
+* javadoc:org.springframework.web.reactive.function.client.WebClient$Builder[] for javadoc:org.springframework.web.reactive.function.client.WebClient[]
+* javadoc:org.springframework.web.client.RestClient$Builder[] for javadoc:org.springframework.web.client.RestClient[]
-You can also manually apply the customizers responsible for this instrumentation, namely `ObservationRestTemplateCustomizer`, `ObservationWebClientCustomizer` and `ObservationRestClientCustomizer`.
+You can also manually apply the customizers responsible for this instrumentation, namely javadoc:org.springframework.boot.actuate.metrics.web.client.ObservationRestTemplateCustomizer[], javadoc:org.springframework.boot.actuate.metrics.web.reactive.client.ObservationWebClientCustomizer[] and javadoc:org.springframework.boot.actuate.metrics.web.client.ObservationRestClientCustomizer[].
By default, metrics are generated with the name, `http.client.requests`.
You can customize the name by setting the configprop:management.observations.http.client.requests.name[] property.
See the {url-spring-framework-docs}/integration/observability.html#observability.http-client[Spring Framework reference documentation for more information on produced observations].
-To customize the tags when using `RestTemplate` or `RestClient`, provide a `@Bean` that implements `ClientRequestObservationConvention` from the `org.springframework.http.client.observation` package.
-To customize the tags when using `WebClient`, provide a `@Bean` that implements `ClientRequestObservationConvention` from the `org.springframework.web.reactive.function.client` package.
+To customize the tags when using javadoc:org.springframework.web.client.RestTemplate[] or javadoc:org.springframework.web.client.RestClient[], provide a javadoc:org.springframework.context.annotation.Bean[format=annotation] that implements javadoc:org.springframework.http.client.observation.ClientRequestObservationConvention[] from the `org.springframework.http.client.observation` package.
+To customize the tags when using javadoc:org.springframework.web.reactive.function.client.WebClient[], provide a javadoc:org.springframework.context.annotation.Bean[format=annotation] that implements javadoc:org.springframework.web.reactive.function.client.ClientRequestObservationConvention[] from the `org.springframework.web.reactive.function.client` package.
[[actuator.metrics.supported.tomcat]]
=== Tomcat Metrics
-Auto-configuration enables the instrumentation of Tomcat only when an MBean `org.apache.tomcat.util.modeler.Registry` is enabled.
+Auto-configuration enables the instrumentation of Tomcat only when an MBean javadoc:org.apache.tomcat.util.modeler.Registry[] is enabled.
By default, the MBean registry is disabled, but you can enable it by setting configprop:server.tomcat.mbeanregistry.enabled[] to `true`.
Tomcat metrics are published under the `tomcat.` meter name.
@@ -898,7 +898,7 @@ Tomcat metrics are published under the `tomcat.` meter name.
[[actuator.metrics.supported.cache]]
=== Cache Metrics
-Auto-configuration enables the instrumentation of all available `Cache` instances on startup, with metrics prefixed with `cache`.
+Auto-configuration enables the instrumentation of all available javadoc:org.springframework.cache.Cache[] instances on startup, with metrics prefixed with `cache`.
Cache instrumentation is standardized for a basic set of metrics.
Additional, cache-specific metrics are also available.
@@ -910,11 +910,11 @@ The following cache libraries are supported:
* Any compliant JCache (JSR-107) implementation
* Redis
-Metrics are tagged by the name of the cache and by the name of the `CacheManager`, which is derived from the bean name.
+Metrics are tagged by the name of the cache and by the name of the javadoc:org.springframework.cache.CacheManager[], which is derived from the bean name.
NOTE: Only caches that are configured on startup are bound to the registry.
For caches not defined in the cache’s configuration, such as caches created on the fly or programmatically after the startup phase, an explicit registration is required.
-A `CacheMetricsRegistrar` bean is made available to make that process easier.
+A javadoc:org.springframework.boot.actuate.metrics.cache.CacheMetricsRegistrar[] bean is made available to make that process easier.
@@ -935,14 +935,14 @@ See the {url-spring-graphql-docs}/observability.html[Spring GraphQL reference do
[[actuator.metrics.supported.jdbc]]
=== DataSource Metrics
-Auto-configuration enables the instrumentation of all available `DataSource` objects with metrics prefixed with `jdbc.connections`.
+Auto-configuration enables the instrumentation of all available javadoc:javax.sql.DataSource[] objects with metrics prefixed with `jdbc.connections`.
Data source instrumentation results in gauges that represent the currently active, idle, maximum allowed, and minimum allowed connections in the pool.
-Metrics are also tagged by the name of the `DataSource` computed based on the bean name.
+Metrics are also tagged by the name of the javadoc:javax.sql.DataSource[] computed based on the bean name.
TIP: By default, Spring Boot provides metadata for all supported data sources.
-You can add additional `DataSourcePoolMetadataProvider` beans if your favorite data source is not supported.
-See `DataSourcePoolMetadataProvidersConfiguration` for examples.
+You can add additional javadoc:org.springframework.boot.jdbc.metadata.DataSourcePoolMetadataProvider[] beans if your favorite data source is not supported.
+See javadoc:org.springframework.boot.autoconfigure.jdbc.metadata.DataSourcePoolMetadataProvidersConfiguration[] for examples.
Also, Hikari-specific metrics are exposed with a `hikaricp` prefix.
Each metric is tagged by the name of the pool (you can control it with `spring.datasource.name`).
@@ -952,12 +952,12 @@ Each metric is tagged by the name of the pool (you can control it with `spring.d
[[actuator.metrics.supported.hibernate]]
=== Hibernate Metrics
-If `org.hibernate.orm:hibernate-micrometer` is on the classpath, all available Hibernate `EntityManagerFactory` instances that have statistics enabled are instrumented with a metric named `hibernate`.
+If `org.hibernate.orm:hibernate-micrometer` is on the classpath, all available Hibernate javadoc:jakarta.persistence.EntityManagerFactory[] instances that have statistics enabled are instrumented with a metric named `hibernate`.
-Metrics are also tagged by the name of the `EntityManagerFactory`, which is derived from the bean name.
+Metrics are also tagged by the name of the javadoc:jakarta.persistence.EntityManagerFactory[], which is derived from the bean name.
To enable statistics, the standard JPA property `hibernate.generate_statistics` must be set to `true`.
-You can enable that on the auto-configured `EntityManagerFactory`:
+You can enable that on the auto-configured javadoc:jakarta.persistence.EntityManagerFactory[]:
[configprops,yaml]
----
@@ -972,14 +972,14 @@ spring:
[[actuator.metrics.supported.spring-data-repository]]
=== Spring Data Repository Metrics
-Auto-configuration enables the instrumentation of all Spring Data `Repository` method invocations.
+Auto-configuration enables the instrumentation of all Spring Data javadoc:org.springframework.data.repository.Repository[] method invocations.
By default, metrics are generated with the name, `spring.data.repository.invocations`.
You can customize the name by setting the configprop:management.metrics.data.repository.metric-name[] property.
-The `@Timed` annotation from the `io.micrometer.core.annotation` package is supported on `Repository` interfaces and methods.
-If you do not want to record metrics for all `Repository` invocations, you can set configprop:management.metrics.data.repository.autotime.enabled[] to `false` and exclusively use `@Timed` annotations instead.
+The javadoc:io.micrometer.core.annotation.Timed[format=annotation] annotation from the `io.micrometer.core.annotation` package is supported on javadoc:org.springframework.data.repository.Repository[] interfaces and methods.
+If you do not want to record metrics for all javadoc:org.springframework.data.repository.Repository[] invocations, you can set configprop:management.metrics.data.repository.autotime.enabled[] to `false` and exclusively use javadoc:io.micrometer.core.annotation.Timed[format=annotation] annotations instead.
-NOTE: A `@Timed` annotation with `longTask = true` enables a long task timer for the method.
+NOTE: A javadoc:io.micrometer.core.annotation.Timed[format=annotation] annotation with `longTask = true` enables a long task timer for the method.
Long task timers require a separate metric name and can be stacked with a short task timer.
By default, repository invocation related metrics are tagged with the following information:
@@ -988,10 +988,10 @@ By default, repository invocation related metrics are tagged with the following
| Tag | Description
| `repository`
-| The simple class name of the source `Repository`.
+| The simple class name of the source javadoc:org.springframework.data.repository.Repository[].
| `method`
-| The name of the `Repository` method that was invoked.
+| The name of the javadoc:org.springframework.data.repository.Repository[] method that was invoked.
| `state`
| The result state (`SUCCESS`, `ERROR`, `CANCELED`, or `RUNNING`).
@@ -1000,7 +1000,7 @@ By default, repository invocation related metrics are tagged with the following
| The simple class name of any exception that was thrown from the invocation.
|===
-To replace the default tags, provide a `@Bean` that implements `RepositoryTagsProvider`.
+To replace the default tags, provide a javadoc:org.springframework.context.annotation.Bean[format=annotation] that implements javadoc:org.springframework.boot.actuate.metrics.data.RepositoryTagsProvider[].
@@ -1014,7 +1014,7 @@ Auto-configuration enables the instrumentation of all available RabbitMQ connect
[[actuator.metrics.supported.spring-integration]]
=== Spring Integration Metrics
-Spring Integration automatically provides {url-spring-integration-docs}/metrics.html#micrometer-integration[Micrometer support] whenever a `MeterRegistry` bean is available.
+Spring Integration automatically provides {url-spring-integration-docs}/metrics.html#micrometer-integration[Micrometer support] whenever a javadoc:io.micrometer.core.instrument.MeterRegistry[] bean is available.
Metrics are published under the `spring.integration.` meter name.
@@ -1022,8 +1022,8 @@ Metrics are published under the `spring.integration.` meter name.
[[actuator.metrics.supported.kafka]]
=== Kafka Metrics
-Auto-configuration registers a `MicrometerConsumerListener` and `MicrometerProducerListener` for the auto-configured consumer factory and producer factory, respectively.
-It also registers a `KafkaStreamsMicrometerListener` for `StreamsBuilderFactoryBean`.
+Auto-configuration registers a javadoc:org.springframework.kafka.core.MicrometerConsumerListener[] and javadoc:org.springframework.kafka.core.MicrometerProducerListener[] for the auto-configured consumer factory and producer factory, respectively.
+It also registers a javadoc:org.springframework.kafka.streams.KafkaStreamsMicrometerListener[] for javadoc:org.springframework.kafka.config.StreamsBuilderFactoryBean[].
For more detail, see the {url-spring-kafka-docs}/kafka/micrometer.html#micrometer-native[Micrometer Native Metrics] section of the Spring Kafka documentation.
@@ -1038,7 +1038,7 @@ This section briefly describes the available metrics for MongoDB.
[[actuator.metrics.supported.mongodb.command]]
==== MongoDB Command Metrics
-Auto-configuration registers a `MongoMetricsCommandListener` with the auto-configured `MongoClient`.
+Auto-configuration registers a javadoc:io.micrometer.core.instrument.binder.mongodb.MongoMetricsCommandListener[] with the auto-configured javadoc:{url-mongodb-driver-sync-javadoc}/com.mongodb.client.MongoClient[].
A timer metric named `mongodb.driver.commands` is created for each command issued to the underlying MongoDB driver.
Each metric is tagged with the following information by default:
@@ -1058,7 +1058,7 @@ Each metric is tagged with the following information by default:
| The outcome of the command (`SUCCESS` or `FAILED`).
|===
-To replace the default metric tags, define a `MongoCommandTagsProvider` bean, as the following example shows:
+To replace the default metric tags, define a javadoc:io.micrometer.core.instrument.binder.mongodb.MongoCommandTagsProvider[] bean, as the following example shows:
include-code::MyCommandTagsProviderConfiguration[]
@@ -1078,7 +1078,7 @@ management:
[[actuator.metrics.supported.mongodb.connection-pool]]
==== MongoDB Connection Pool Metrics
-Auto-configuration registers a `MongoMetricsConnectionPoolListener` with the auto-configured `MongoClient`.
+Auto-configuration registers a javadoc:io.micrometer.core.instrument.binder.mongodb.MongoMetricsConnectionPoolListener[] with the auto-configured javadoc:{url-mongodb-driver-sync-javadoc}/com.mongodb.client.MongoClient[].
The following gauge metrics are created for the connection pool:
@@ -1097,7 +1097,7 @@ Each metric is tagged with the following information by default:
| The address of the server to which the connection pool corresponds.
|===
-To replace the default metric tags, define a `MongoConnectionPoolTagsProvider` bean:
+To replace the default metric tags, define a javadoc:io.micrometer.core.instrument.binder.mongodb.MongoConnectionPoolTagsProvider[] bean:
include-code::MyConnectionPoolTagsProviderConfiguration[]
@@ -1117,15 +1117,15 @@ management:
[[actuator.metrics.supported.jetty]]
=== Jetty Metrics
-Auto-configuration binds metrics for Jetty's `ThreadPool` by using Micrometer's `JettyServerThreadPoolMetrics`.
-Metrics for Jetty's `Connector` instances are bound by using Micrometer's `JettyConnectionMetrics` and, when configprop:server.ssl.enabled[] is set to `true`, Micrometer's `JettySslHandshakeMetrics`.
+Auto-configuration binds metrics for Jetty's javadoc:org.eclipse.jetty.util.thread.ThreadPool[] by using Micrometer's javadoc:io.micrometer.core.instrument.binder.jetty.JettyServerThreadPoolMetrics[].
+Metrics for Jetty's javadoc:org.eclipse.jetty.server.Connector[] instances are bound by using Micrometer's javadoc:io.micrometer.core.instrument.binder.jetty.JettyConnectionMetrics[] and, when configprop:server.ssl.enabled[] is set to `true`, Micrometer's javadoc:io.micrometer.core.instrument.binder.jetty.JettySslHandshakeMetrics[].
[[actuator.metrics.supported.timed-annotation]]
=== @Timed Annotation Support
-To enable scanning of `@Timed` annotations, you will need to set the configprop:management.observations.annotations.enabled[] property to `true`.
+To enable scanning of javadoc:io.micrometer.core.annotation.Timed[format=annotation] annotations, you will need to set the configprop:management.observations.annotations.enabled[] property to `true`.
Please refer to the {url-micrometer-docs-concepts}/timers.html#_the_timed_annotation[Micrometer documentation].
@@ -1133,7 +1133,7 @@ Please refer to the {url-micrometer-docs-concepts}/timers.html#_the_timed_annota
[[actuator.metrics.supported.redis]]
=== Redis Metrics
-Auto-configuration registers a `MicrometerCommandLatencyRecorder` for the auto-configured `LettuceConnectionFactory`.
+Auto-configuration registers a javadoc:io.lettuce.core.metrics.MicrometerCommandLatencyRecorder[] for the auto-configured javadoc:org.springframework.data.redis.connection.lettuce.LettuceConnectionFactory[].
For more detail, see the {url-lettuce-docs}#command.latency.metrics.micrometer[Micrometer Metrics section] of the Lettuce documentation.
@@ -1141,32 +1141,32 @@ For more detail, see the {url-lettuce-docs}#command.latency.metrics.micrometer[M
[[actuator.metrics.registering-custom]]
== Registering Custom Metrics
-To register custom metrics, inject `MeterRegistry` into your component:
+To register custom metrics, inject javadoc:io.micrometer.core.instrument.MeterRegistry[] into your component:
include-code::MyBean[]
-If your metrics depend on other beans, we recommend that you use a `MeterBinder` to register them:
+If your metrics depend on other beans, we recommend that you use a javadoc:io.micrometer.core.instrument.binder.MeterBinder[] to register them:
include-code::MyMeterBinderConfiguration[]
-Using a `MeterBinder` ensures that the correct dependency relationships are set up and that the bean is available when the metric's value is retrieved.
-A `MeterBinder` implementation can also be useful if you find that you repeatedly instrument a suite of metrics across components or applications.
+Using a javadoc:io.micrometer.core.instrument.binder.MeterBinder[] ensures that the correct dependency relationships are set up and that the bean is available when the metric's value is retrieved.
+A javadoc:io.micrometer.core.instrument.binder.MeterBinder[] implementation can also be useful if you find that you repeatedly instrument a suite of metrics across components or applications.
-NOTE: By default, metrics from all `MeterBinder` beans are automatically bound to the Spring-managed `MeterRegistry`.
+NOTE: By default, metrics from all javadoc:io.micrometer.core.instrument.binder.MeterBinder[] beans are automatically bound to the Spring-managed javadoc:io.micrometer.core.instrument.MeterRegistry[].
[[actuator.metrics.customizing]]
== Customizing Individual Metrics
-If you need to apply customizations to specific `Meter` instances, you can use the `io.micrometer.core.instrument.config.MeterFilter` interface.
+If you need to apply customizations to specific javadoc:io.micrometer.core.instrument.Meter[] instances, you can use the javadoc:io.micrometer.core.instrument.config.MeterFilter[] interface.
For example, if you want to rename the `mytag.region` tag to `mytag.area` for all meter IDs beginning with `com.example`, you can do the following:
include-code::MyMetricsFilterConfiguration[]
-NOTE: By default, all `MeterFilter` beans are automatically bound to the Spring-managed `MeterRegistry`.
-Make sure to register your metrics by using the Spring-managed `MeterRegistry` and not any of the static methods on `Metrics`.
+NOTE: By default, all javadoc:io.micrometer.core.instrument.config.MeterFilter[] beans are automatically bound to the Spring-managed javadoc:io.micrometer.core.instrument.MeterRegistry[].
+Make sure to register your metrics by using the Spring-managed javadoc:io.micrometer.core.instrument.MeterRegistry[] and not any of the static methods on javadoc:io.micrometer.core.instrument.Metrics[].
These use the global registry that is not Spring-managed.
@@ -1189,15 +1189,15 @@ management:
The preceding example adds `region` and `stack` tags to all meters with a value of `us-east-1` and `prod`, respectively.
NOTE: The order of common tags is important if you use Graphite.
-As the order of common tags cannot be guaranteed by using this approach, Graphite users are advised to define a custom `MeterFilter` instead.
+As the order of common tags cannot be guaranteed by using this approach, Graphite users are advised to define a custom javadoc:io.micrometer.core.instrument.config.MeterFilter[] instead.
[[actuator.metrics.customizing.per-meter-properties]]
=== Per-meter Properties
-In addition to `MeterFilter` beans, you can apply a limited set of customization on a per-meter basis using properties.
-Per-meter customizations are applied, using Spring Boot's `PropertiesMeterFilter`, to any meter IDs that start with the given name.
+In addition to javadoc:io.micrometer.core.instrument.config.MeterFilter[] beans, you can apply a limited set of customization on a per-meter basis using properties.
+Per-meter customizations are applied, using Spring Boot's javadoc:org.springframework.boot.actuate.autoconfigure.metrics.PropertiesMeterFilter[], to any meter IDs that start with the given name.
The following example filters out any meters that have an ID starting with `example.remote`.
[configprops,yaml]
@@ -1217,7 +1217,7 @@ The following properties allow per-meter customization:
| configprop:management.metrics.enable[]
| Whether to accept meters with certain IDs.
- Meters that are not accepted are filtered from the `MeterRegistry`.
+ Meters that are not accepted are filtered from the javadoc:io.micrometer.core.instrument.MeterRegistry[].
| configprop:management.metrics.distribution.percentiles-histogram[]
| Whether to publish a histogram suitable for computing aggregable (across dimension) percentile approximations.
@@ -1270,4 +1270,4 @@ If you wanted to see only the maximum size for the "`Metaspace`", you could add
[[actuator.metrics.micrometer-observation]]
== Integration with Micrometer Observation
-A `DefaultMeterObservationHandler` is automatically registered on the `ObservationRegistry`, which creates metrics for every completed observation.
+A javadoc:io.micrometer.core.instrument.observation.DefaultMeterObservationHandler[] is automatically registered on the javadoc:io.micrometer.observation.ObservationRegistry[], which creates metrics for every completed observation.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/observability.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/observability.adoc
index 0d45c53d1e..1e0af36b43 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/observability.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/observability.adoc
@@ -5,17 +5,17 @@ Observability is the ability to observe the internal state of a running system f
It consists of the three pillars: logging, metrics and traces.
For metrics and traces, Spring Boot uses {url-micrometer-docs}/observation[Micrometer Observation].
-To create your own observations (which will lead to metrics and traces), you can inject an `ObservationRegistry`.
+To create your own observations (which will lead to metrics and traces), you can inject an javadoc:io.micrometer.observation.ObservationRegistry[].
include-code::MyCustomObservation[]
NOTE: Low cardinality tags will be added to metrics and traces, while high cardinality tags will only be added to traces.
-Beans of type `ObservationPredicate`, `GlobalObservationConvention`, `ObservationFilter` and `ObservationHandler` will be automatically registered on the `ObservationRegistry`.
-You can additionally register any number of `ObservationRegistryCustomizer` beans to further configure the registry.
+Beans of type javadoc:io.micrometer.observation.ObservationPredicate[], javadoc:io.micrometer.observation.GlobalObservationConvention[], javadoc:io.micrometer.observation.ObservationFilter[] and javadoc:io.micrometer.observation.ObservationHandler[] will be automatically registered on the javadoc:io.micrometer.observation.ObservationRegistry[].
+You can additionally register any number of javadoc:org.springframework.boot.actuate.autoconfigure.observation.ObservationRegistryCustomizer[] beans to further configure the registry.
Observability support relies on the https://github.com/micrometer-metrics/context-propagation[Context Propagation library] for forwarding the current observation across threads and reactive pipelines.
-By default, `ThreadLocal` values are not automatically reinstated in reactive operators.
+By default, javadoc:java.lang.ThreadLocal[] values are not automatically reinstated in reactive operators.
This behavior is controlled with the configprop:spring.reactor.context-propagation[] property, which can be set to `auto` to enable automatic propagation.
For more details about observations please see the {url-micrometer-docs}/observation[Micrometer Observation documentation].
@@ -69,8 +69,8 @@ The preceding example will prevent all observations with a name starting with `d
TIP: If you want to prevent Spring Security from reporting observations, set the property configprop:management.observations.enable.spring.security[] to `false`.
-If you need greater control over the prevention of observations, you can register beans of type `ObservationPredicate`.
-Observations are only reported if all the `ObservationPredicate` beans return `true` for that observation.
+If you need greater control over the prevention of observations, you can register beans of type javadoc:io.micrometer.observation.ObservationPredicate[].
+Observations are only reported if all the javadoc:io.micrometer.observation.ObservationPredicate[] beans return `true` for that observation.
include-code::MyObservationPredicate[]
@@ -89,10 +89,10 @@ the metrics and traces use the semantic conventions described in the Spring proj
Spring Boot's actuator module includes basic support for OpenTelemetry.
-It provides a bean of type `OpenTelemetry`, and if there are beans of type `SdkTracerProvider`, `ContextPropagators`, `SdkLoggerProvider` or `SdkMeterProvider` in the application context, they automatically get registered.
-Additionally, it provides a `Resource` bean.
-The attributes of the auto-configured `Resource` can be configured via the configprop:management.opentelemetry.resource-attributes[] configuration property.
-If you have defined your own `Resource` bean, this will no longer be the case.
+It provides a bean of type javadoc:io.opentelemetry.api.OpenTelemetry[], and if there are beans of type javadoc:io.opentelemetry.sdk.trace.SdkTracerProvider[], javadoc:io.opentelemetry.context.propagation.ContextPropagators[], javadoc:io.opentelemetry.sdk.logs.SdkLoggerProvider[] or javadoc:io.opentelemetry.sdk.metrics.SdkMeterProvider[] in the application context, they automatically get registered.
+Additionally, it provides a javadoc:io.opentelemetry.sdk.resources.Resource[] bean.
+The attributes of the auto-configured javadoc:io.opentelemetry.sdk.resources.Resource[] can be configured via the configprop:management.opentelemetry.resource-attributes[] configuration property.
+If you have defined your own javadoc:io.opentelemetry.sdk.resources.Resource[] bean, this will no longer be the case.
NOTE: Spring Boot does not provide auto-configuration for OpenTelemetry metrics or logging.
OpenTelemetry tracing is only auto-configured when used together with xref:actuator/tracing.adoc[Micrometer Tracing].
@@ -104,5 +104,5 @@ The next sections will provide more details about logging, metrics and traces.
[[actuator.observability.annotations]]
== Micrometer Observation Annotations support
-To enable scanning of metrics and tracing annotations like `@Timed`, `@Counted`, `@MeterTag` and `@NewSpan` annotations, you will need to set the configprop:management.observations.annotations.enabled[] property to `true`.
+To enable scanning of metrics and tracing annotations like javadoc:io.micrometer.core.annotation.Timed[format=annotation], javadoc:io.micrometer.core.annotation.Counted[format=annotation], javadoc:io.micrometer.core.aop.MeterTag[format=annotation] and javadoc:io.micrometer.tracing.annotation.NewSpan[format=annotation] annotations, you will need to set the configprop:management.observations.annotations.enabled[] property to `true`.
This feature is supported Micrometer directly. Please refer to the {url-micrometer-docs-concepts}/timers.html#_the_timed_annotation[Micrometer] and {url-micrometer-tracing-docs}/api.html#_aspect_oriented_programming[Micrometer Tracing] reference docs.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/process-monitoring.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/process-monitoring.adoc
index 58e37cf041..b3059e8a86 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/process-monitoring.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/process-monitoring.adoc
@@ -3,8 +3,8 @@
In the `spring-boot` module, you can find two classes to create files that are often useful for process monitoring:
-* `ApplicationPidFileWriter` creates a file that contains the application PID (by default, in the application directory with a file name of `application.pid`).
-* `WebServerPortFileWriter` creates a file (or files) that contain the ports of the running web server (by default, in the application directory with a file name of `application.port`).
+* javadoc:org.springframework.boot.context.ApplicationPidFileWriter[] creates a file that contains the application PID (by default, in the application directory with a file name of `application.pid`).
+* javadoc:org.springframework.boot.web.context.WebServerPortFileWriter[] creates a file (or files) that contain the ports of the running web server (by default, in the application directory with a file name of `application.port`).
By default, these writers are not activated, but you can enable them:
@@ -30,5 +30,5 @@ org.springframework.boot.web.context.WebServerPortFileWriter
[[actuator.process-monitoring.programmatically]]
== Programmatically Enabling Process Monitoring
-You can also activate a listener by invoking the `SpringApplication.addListeners(...)` method and passing the appropriate `Writer` object.
-This method also lets you customize the file name and path in the `Writer` constructor.
+You can also activate a listener by invoking the `SpringApplication.addListeners(...)` method and passing the appropriate javadoc:java.io.Writer[] object.
+This method also lets you customize the file name and path in the javadoc:java.io.Writer[] constructor.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/tracing.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/tracing.adoc
index fcddb23e42..56a9f124c4 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/tracing.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/tracing.adoc
@@ -100,7 +100,7 @@ It's also worth mentioning that configprop:logging.pattern.correlation[] contain
To automatically propagate traces over the network, use the auto-configured xref:io/rest-client.adoc#io.rest-client.resttemplate[`RestTemplateBuilder`], xref:io/rest-client.adoc#io.rest-client.restclient[`RestClient.Builder`] or xref:io/rest-client.adoc#io.rest-client.webclient[`WebClient.Builder`] to construct the client.
-WARNING: If you create the `RestTemplate`, the `RestClient` or the `WebClient` without using the auto-configured builders, automatic trace propagation won't work!
+WARNING: If you create the javadoc:org.springframework.web.client.RestTemplate[], the javadoc:org.springframework.web.client.RestClient[] or the javadoc:org.springframework.web.reactive.function.client.WebClient[] without using the auto-configured builders, automatic trace propagation won't work!
@@ -176,7 +176,7 @@ Use the `management.wavefront.*` configuration properties to configure reporting
[[actuator.micrometer-tracing.micrometer-observation]]
== Integration with Micrometer Observation
-A `TracingAwareMeterObservationHandler` is automatically registered on the `ObservationRegistry`, which creates spans for every completed observation.
+A javadoc:io.micrometer.tracing.handler.TracingAwareMeterObservationHandler[] is automatically registered on the javadoc:io.micrometer.observation.ObservationRegistry[], which creates spans for every completed observation.
@@ -184,7 +184,7 @@ A `TracingAwareMeterObservationHandler` is automatically registered on the `Obse
== Creating Custom Spans
You can create your own spans by starting an observation.
-For this, inject `ObservationRegistry` into your component:
+For this, inject javadoc:io.micrometer.observation.ObservationRegistry[] into your component:
include-code::CustomObservation[]
@@ -197,7 +197,7 @@ TIP: If you want to create a span without creating a metric, you need to use the
[[actuator.micrometer-tracing.baggage]]
== Baggage
-You can create baggage with the `Tracer` API:
+You can create baggage with the javadoc:io.micrometer.tracing.Tracer[] API:
include-code::CreatingBaggage[]
@@ -215,5 +215,5 @@ For the example above, setting this property to `baggage1` results in an MDC ent
[[actuator.micrometer-tracing.tests]]
== Tests
-Tracing components which are reporting data are not auto-configured when using `@SpringBootTest`.
+Tracing components which are reporting data are not auto-configured when using javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation].
See xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.tracing[] for more details.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/data/nosql.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/data/nosql.adoc
index ccce2a70a4..c4e8a9dcaa 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/data/nosql.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/data/nosql.adoc
@@ -38,7 +38,7 @@ TIP: We also provide a `spring-boot-starter-data-redis-reactive` starter for con
[[data.nosql.redis.connecting]]
=== Connecting to Redis
-You can inject an auto-configured `RedisConnectionFactory`, `StringRedisTemplate`, or vanilla `RedisTemplate` instance as you would any other Spring Bean.
+You can inject an auto-configured javadoc:org.springframework.data.redis.connection.RedisConnectionFactory[], javadoc:org.springframework.data.redis.core.StringRedisTemplate[], or vanilla javadoc:org.springframework.data.redis.core.RedisTemplate[] instance as you would any other Spring Bean.
The following listing shows an example of such a bean:
include-code::MyBean[]
@@ -72,16 +72,16 @@ spring:
----
-TIP: You can also register an arbitrary number of beans that implement `LettuceClientConfigurationBuilderCustomizer` for more advanced customizations.
-`ClientResources` can also be customized using `ClientResourcesBuilderCustomizer`.
-If you use Jedis, `JedisClientConfigurationBuilderCustomizer` is also available.
-Alternatively, you can register a bean of type `RedisStandaloneConfiguration`, `RedisSentinelConfiguration`, or `RedisClusterConfiguration` to take full control over the configuration.
+TIP: You can also register an arbitrary number of beans that implement javadoc:org.springframework.boot.autoconfigure.data.redis.LettuceClientConfigurationBuilderCustomizer[] for more advanced customizations.
+javadoc:io.lettuce.core.resource.ClientResources[] can also be customized using javadoc:org.springframework.boot.autoconfigure.data.redis.ClientResourcesBuilderCustomizer[].
+If you use Jedis, javadoc:org.springframework.boot.autoconfigure.data.redis.JedisClientConfigurationBuilderCustomizer[] is also available.
+Alternatively, you can register a bean of type javadoc:org.springframework.data.redis.connection.RedisStandaloneConfiguration[], javadoc:org.springframework.data.redis.connection.RedisSentinelConfiguration[], or javadoc:org.springframework.data.redis.connection.RedisClusterConfiguration[] to take full control over the configuration.
-If you add your own `@Bean` of any of the auto-configured types, it replaces the default (except in the case of `RedisTemplate`, when the exclusion is based on the bean name, `redisTemplate`, not its type).
+If you add your own javadoc:org.springframework.context.annotation.Bean[format=annotation] of any of the auto-configured types, it replaces the default (except in the case of javadoc:org.springframework.data.redis.core.RedisTemplate[], when the exclusion is based on the bean name, `redisTemplate`, not its type).
By default, a pooled connection factory is auto-configured if `commons-pool2` is on the classpath.
-The auto-configured `RedisConnectionFactory` can be configured to use SSL for communication with the server by setting the properties as shown in this example:
+The auto-configured javadoc:org.springframework.data.redis.connection.RedisConnectionFactory[] can be configured to use SSL for communication with the server by setting the properties as shown in this example:
[configprops,yaml]
----
@@ -92,7 +92,7 @@ spring:
enabled: true
----
-Custom SSL trust material can be configured in an xref:features/ssl.adoc[SSL bundle] and applied to the `RedisConnectionFactory` as shown in this example:
+Custom SSL trust material can be configured in an xref:features/ssl.adoc[SSL bundle] and applied to the javadoc:org.springframework.data.redis.connection.RedisConnectionFactory[] as shown in this example:
[configprops,yaml]
----
@@ -116,19 +116,19 @@ Spring Boot offers several conveniences for working with MongoDB, including the
[[data.nosql.mongodb.connecting]]
=== Connecting to a MongoDB Database
-To access MongoDB databases, you can inject an auto-configured `org.springframework.data.mongodb.MongoDatabaseFactory`.
+To access MongoDB databases, you can inject an auto-configured javadoc:org.springframework.data.mongodb.MongoDatabaseFactory[].
By default, the instance tries to connect to a MongoDB server at `mongodb://localhost/test`.
The following example shows how to connect to a MongoDB database:
include-code::MyBean[]
-If you have defined your own `MongoClient`, it will be used to auto-configure a suitable `MongoDatabaseFactory`.
+If you have defined your own javadoc:{url-mongodb-driver-sync-javadoc}/com.mongodb.client.MongoClient[], it will be used to auto-configure a suitable javadoc:org.springframework.data.mongodb.MongoDatabaseFactory[].
-The auto-configured `MongoClient` is created using a `MongoClientSettings` bean.
-If you have defined your own `MongoClientSettings`, it will be used without modification and the `spring.data.mongodb` properties will be ignored.
-Otherwise a `MongoClientSettings` will be auto-configured and will have the `spring.data.mongodb` properties applied to it.
-In either case, you can declare one or more `MongoClientSettingsBuilderCustomizer` beans to fine-tune the `MongoClientSettings` configuration.
-Each will be called in order with the `MongoClientSettings.Builder` that is used to build the `MongoClientSettings`.
+The auto-configured javadoc:{url-mongodb-driver-sync-javadoc}/com.mongodb.client.MongoClient[] is created using a javadoc:{url-mongodb-driver-core-javadoc}/com.mongodb.MongoClientSettings[] bean.
+If you have defined your own javadoc:{url-mongodb-driver-core-javadoc}/com.mongodb.MongoClientSettings[], it will be used without modification and the `spring.data.mongodb` properties will be ignored.
+Otherwise a javadoc:{url-mongodb-driver-core-javadoc}/com.mongodb.MongoClientSettings[] will be auto-configured and will have the `spring.data.mongodb` properties applied to it.
+In either case, you can declare one or more javadoc:org.springframework.boot.autoconfigure.mongo.MongoClientSettingsBuilderCustomizer[] beans to fine-tune the javadoc:{url-mongodb-driver-core-javadoc}/com.mongodb.MongoClientSettings[] configuration.
+Each will be called in order with the javadoc:{url-mongodb-driver-core-javadoc}/com.mongodb.MongoClientSettings$Builder[] that is used to build the javadoc:{url-mongodb-driver-core-javadoc}/com.mongodb.MongoClientSettings[].
You can set the configprop:spring.data.mongodb.uri[] property to change the URL and configure additional settings such as the _replica set_, as shown in the following example:
@@ -157,7 +157,7 @@ spring:
password: "secret"
----
-The auto-configured `MongoClient` can be configured to use SSL for communication with the server by setting the properties as shown in this example:
+The auto-configured javadoc:{url-mongodb-driver-sync-javadoc}/com.mongodb.client.MongoClient[] can be configured to use SSL for communication with the server by setting the properties as shown in this example:
[configprops,yaml]
----
@@ -169,7 +169,7 @@ spring:
enabled: true
----
-Custom SSL trust material can be configured in an xref:features/ssl.adoc[SSL bundle] and applied to the `MongoClient` as shown in this example:
+Custom SSL trust material can be configured in an xref:features/ssl.adoc[SSL bundle] and applied to the javadoc:{url-mongodb-driver-sync-javadoc}/com.mongodb.client.MongoClient[] as shown in this example:
[configprops,yaml]
----
@@ -191,8 +191,8 @@ You can also specify the port as part of the host address by using the `host:por
This format should be used if you need to change the port of an `additional-hosts` entry.
====
-TIP: If you do not use Spring Data MongoDB, you can inject a `MongoClient` bean instead of using `MongoDatabaseFactory`.
-If you want to take complete control of establishing the MongoDB connection, you can also declare your own `MongoDatabaseFactory` or `MongoClient` bean.
+TIP: If you do not use Spring Data MongoDB, you can inject a javadoc:{url-mongodb-driver-sync-javadoc}/com.mongodb.client.MongoClient[] bean instead of using javadoc:org.springframework.data.mongodb.MongoDatabaseFactory[].
+If you want to take complete control of establishing the MongoDB connection, you can also declare your own javadoc:org.springframework.data.mongodb.MongoDatabaseFactory[] or javadoc:{url-mongodb-driver-sync-javadoc}/com.mongodb.client.MongoClient[] bean.
NOTE: If you are using the reactive driver, Netty is required for SSL.
The auto-configuration configures this factory automatically if Netty is available and the factory to use has not been customized already.
@@ -202,8 +202,8 @@ The auto-configuration configures this factory automatically if Netty is availab
[[data.nosql.mongodb.template]]
=== MongoTemplate
-{url-spring-data-mongodb-site}[Spring Data MongoDB] provides a javadoc:{url-spring-data-mongodb-javadoc}/org.springframework.data.mongodb.core.MongoTemplate[] class that is very similar in its design to Spring's `JdbcTemplate`.
-As with `JdbcTemplate`, Spring Boot auto-configures a bean for you to inject the template, as follows:
+{url-spring-data-mongodb-site}[Spring Data MongoDB] provides a javadoc:{url-spring-data-mongodb-javadoc}/org.springframework.data.mongodb.core.MongoTemplate[] class that is very similar in its design to Spring's javadoc:org.springframework.jdbc.core.JdbcTemplate[].
+As with javadoc:org.springframework.jdbc.core.JdbcTemplate[], Spring Boot auto-configures a bean for you to inject the template, as follows:
include-code::MyBean[]
@@ -218,13 +218,13 @@ Spring Data includes repository support for MongoDB.
As with the JPA repositories discussed earlier, the basic principle is that queries are constructed automatically, based on method names.
In fact, both Spring Data JPA and Spring Data MongoDB share the same common infrastructure.
-You could take the JPA example from earlier and, assuming that `City` is now a MongoDB data class rather than a JPA `@Entity`, it works in the same way, as shown in the following example:
+You could take the JPA example from earlier and, assuming that `City` is now a MongoDB data class rather than a JPA javadoc:jakarta.persistence.Entity[format=annotation], it works in the same way, as shown in the following example:
include-code::CityRepository[]
Repositories and documents are found through scanning.
By default, the xref:using/auto-configuration.adoc#using.auto-configuration.packages[auto-configuration packages] are scanned.
-You can customize the locations to look for repositories and documents by using `@EnableMongoRepositories` and `@EntityScan` respectively.
+You can customize the locations to look for repositories and documents by using javadoc:org.springframework.data.mongodb.repository.config.EnableMongoRepositories[format=annotation] and javadoc:org.springframework.boot.autoconfigure.domain.EntityScan[format=annotation] respectively.
TIP: For complete details of Spring Data MongoDB, including its rich object mapping technologies, see its {url-spring-data-mongodb-docs}[reference documentation].
@@ -241,9 +241,9 @@ Spring Boot offers several conveniences for working with Neo4j, including the `s
[[data.nosql.neo4j.connecting]]
=== Connecting to a Neo4j Database
-To access a Neo4j server, you can inject an auto-configured `org.neo4j.driver.Driver`.
+To access a Neo4j server, you can inject an auto-configured javadoc:org.neo4j.driver.Driver[].
By default, the instance tries to connect to a Neo4j server at `localhost:7687` using the Bolt protocol.
-The following example shows how to inject a Neo4j `Driver` that gives you access, amongst other things, to a `Session`:
+The following example shows how to inject a Neo4j javadoc:org.neo4j.driver.Driver[] that gives you access, amongst other things, to a javadoc:org.neo4j.driver.Session[]:
include-code::MyBean[]
@@ -260,9 +260,9 @@ spring:
password: "secret"
----
-The auto-configured `Driver` is created using `ConfigBuilder`.
-To fine-tune its configuration, declare one or more `ConfigBuilderCustomizer` beans.
-Each will be called in order with the `ConfigBuilder` that is used to build the `Driver`.
+The auto-configured javadoc:org.neo4j.driver.Driver[] is created using `org.neo4j.driver.Config$ConfigBuilder`.
+To fine-tune its configuration, declare one or more javadoc:org.springframework.boot.autoconfigure.neo4j.ConfigBuilderCustomizer[] beans.
+Each will be called in order with the `org.neo4j.driver.Config$ConfigBuilder` that is used to build the javadoc:org.neo4j.driver.Driver[].
@@ -273,21 +273,21 @@ Spring Data includes repository support for Neo4j.
For complete details of Spring Data Neo4j, see the {url-spring-data-neo4j-docs}[reference documentation].
Spring Data Neo4j shares the common infrastructure with Spring Data JPA as many other Spring Data modules do.
-You could take the JPA example from earlier and define `City` as Spring Data Neo4j `@Node` rather than JPA `@Entity` and the repository abstraction works in the same way, as shown in the following example:
+You could take the JPA example from earlier and define `City` as Spring Data Neo4j javadoc:org.springframework.data.neo4j.core.schema.Node[format=annotation] rather than JPA javadoc:jakarta.persistence.Entity[format=annotation] and the repository abstraction works in the same way, as shown in the following example:
include-code::CityRepository[]
The `spring-boot-starter-data-neo4j` starter enables the repository support as well as transaction management.
-Spring Boot supports both classic and reactive Neo4j repositories, using the `Neo4jTemplate` or `ReactiveNeo4jTemplate` beans.
+Spring Boot supports both classic and reactive Neo4j repositories, using the javadoc:org.springframework.data.neo4j.core.Neo4jTemplate[] or javadoc:org.springframework.data.neo4j.core.ReactiveNeo4jTemplate[] beans.
When Project Reactor is available on the classpath, the reactive style is also auto-configured.
Repositories and entities are found through scanning.
By default, the xref:using/auto-configuration.adoc#using.auto-configuration.packages[auto-configuration packages] are scanned.
-You can customize the locations to look for repositories and entities by using `@EnableNeo4jRepositories` and `@EntityScan` respectively.
+You can customize the locations to look for repositories and entities by using javadoc:org.springframework.data.neo4j.repository.config.EnableNeo4jRepositories[format=annotation] and javadoc:org.springframework.boot.autoconfigure.domain.EntityScan[format=annotation] respectively.
[NOTE]
====
-In an application using the reactive style, a `ReactiveTransactionManager` is not auto-configured.
+In an application using the reactive style, a javadoc:org.springframework.transaction.ReactiveTransactionManager[] is not auto-configured.
To enable transaction management, the following bean must be defined in your configuration:
include-code::MyNeo4jConfiguration[]
@@ -305,7 +305,7 @@ Spring Boot supports several clients:
* The official low-level REST client
* The official Java API client
-* The `ReactiveElasticsearchClient` provided by Spring Data Elasticsearch
+* The javadoc:org.springframework.data.elasticsearch.client.elc.ReactiveElasticsearchClient[] provided by Spring Data Elasticsearch
Spring Boot provides a dedicated starter, `spring-boot-starter-data-elasticsearch`.
@@ -334,14 +334,14 @@ spring:
[[data.nosql.elasticsearch.connecting-using-rest.restclient]]
==== Connecting to Elasticsearch Using RestClient
-If you have `elasticsearch-rest-client` on the classpath, Spring Boot will auto-configure and register a `RestClient` bean.
-In addition to the properties described previously, to fine-tune the `RestClient` you can register an arbitrary number of beans that implement `RestClientBuilderCustomizer` for more advanced customizations.
-To take full control over the clients' configuration, define a `RestClientBuilder` bean.
+If you have `elasticsearch-rest-client` on the classpath, Spring Boot will auto-configure and register a javadoc:org.springframework.web.client.RestClient[] bean.
+In addition to the properties described previously, to fine-tune the javadoc:org.springframework.web.client.RestClient[] you can register an arbitrary number of beans that implement javadoc:org.springframework.boot.autoconfigure.elasticsearch.RestClientBuilderCustomizer[] for more advanced customizations.
+To take full control over the clients' configuration, define a javadoc:org.elasticsearch.client.RestClientBuilder[] bean.
-Additionally, if `elasticsearch-rest-client-sniffer` is on the classpath, a `Sniffer` is auto-configured to automatically discover nodes from a running Elasticsearch cluster and set them on the `RestClient` bean.
-You can further tune how `Sniffer` is configured, as shown in the following example:
+Additionally, if `elasticsearch-rest-client-sniffer` is on the classpath, a javadoc:org.elasticsearch.client.sniff.Sniffer[] is auto-configured to automatically discover nodes from a running Elasticsearch cluster and set them on the javadoc:org.springframework.web.client.RestClient[] bean.
+You can further tune how javadoc:org.elasticsearch.client.sniff.Sniffer[] is configured, as shown in the following example:
[configprops,yaml]
----
@@ -358,38 +358,38 @@ spring:
[[data.nosql.elasticsearch.connecting-using-rest.javaapiclient]]
==== Connecting to Elasticsearch Using ElasticsearchClient
-If you have `co.elastic.clients:elasticsearch-java` on the classpath, Spring Boot will auto-configure and register an `ElasticsearchClient` bean.
+If you have `co.elastic.clients:elasticsearch-java` on the classpath, Spring Boot will auto-configure and register an javadoc:co.elastic.clients.elasticsearch.ElasticsearchClient[] bean.
-The `ElasticsearchClient` uses a transport that depends upon the previously described `RestClient`.
-Therefore, the properties described previously can be used to configure the `ElasticsearchClient`.
-Furthermore, you can define a `RestClientOptions` bean to take further control of the behavior of the transport.
+The javadoc:co.elastic.clients.elasticsearch.ElasticsearchClient[] uses a transport that depends upon the previously described javadoc:org.springframework.web.client.RestClient[].
+Therefore, the properties described previously can be used to configure the javadoc:co.elastic.clients.elasticsearch.ElasticsearchClient[].
+Furthermore, you can define a javadoc:co.elastic.clients.transport.rest_client.RestClientOptions[] bean to take further control of the behavior of the transport.
[[data.nosql.elasticsearch.connecting-using-rest.reactiveclient]]
==== Connecting to Elasticsearch using ReactiveElasticsearchClient
-{url-spring-data-elasticsearch-site}[Spring Data Elasticsearch] ships `ReactiveElasticsearchClient` for querying Elasticsearch instances in a reactive fashion.
-If you have Spring Data Elasticsearch and Reactor on the classpath, Spring Boot will auto-configure and register a `ReactiveElasticsearchClient`.
+{url-spring-data-elasticsearch-site}[Spring Data Elasticsearch] ships javadoc:org.springframework.data.elasticsearch.client.elc.ReactiveElasticsearchClient[] for querying Elasticsearch instances in a reactive fashion.
+If you have Spring Data Elasticsearch and Reactor on the classpath, Spring Boot will auto-configure and register a javadoc:org.springframework.data.elasticsearch.client.elc.ReactiveElasticsearchClient[].
-The `ReactiveElasticsearchClient` uses a transport that depends upon the previously described `RestClient`.
-Therefore, the properties described previously can be used to configure the `ReactiveElasticsearchClient`.
-Furthermore, you can define a `RestClientOptions` bean to take further control of the behavior of the transport.
+The javadoc:org.springframework.data.elasticsearch.client.elc.ReactiveElasticsearchClient[] uses a transport that depends upon the previously described javadoc:org.springframework.web.client.RestClient[].
+Therefore, the properties described previously can be used to configure the javadoc:org.springframework.data.elasticsearch.client.elc.ReactiveElasticsearchClient[].
+Furthermore, you can define a javadoc:co.elastic.clients.transport.rest_client.RestClientOptions[] bean to take further control of the behavior of the transport.
[[data.nosql.elasticsearch.connecting-using-spring-data]]
=== Connecting to Elasticsearch by Using Spring Data
-To connect to Elasticsearch, an `ElasticsearchClient` bean must be defined,
+To connect to Elasticsearch, an javadoc:co.elastic.clients.elasticsearch.ElasticsearchClient[] bean must be defined,
auto-configured by Spring Boot or manually provided by the application (see previous sections).
With this configuration in place, an
-`ElasticsearchTemplate` can be injected like any other Spring bean,
+javadoc:org.springframework.data.elasticsearch.client.elc.ElasticsearchTemplate[] can be injected like any other Spring bean,
as shown in the following example:
include-code::MyBean[]
-In the presence of `spring-data-elasticsearch` and Reactor, Spring Boot can also auto-configure a xref:data/nosql.adoc#data.nosql.elasticsearch.connecting-using-rest.reactiveclient[`ReactiveElasticsearchClient`] and a `ReactiveElasticsearchTemplate` as beans.
+In the presence of `spring-data-elasticsearch` and Reactor, Spring Boot can also auto-configure a xref:data/nosql.adoc#data.nosql.elasticsearch.connecting-using-rest.reactiveclient[`ReactiveElasticsearchClient`] and a javadoc:org.springframework.data.elasticsearch.client.elc.ReactiveElasticsearchTemplate[] as beans.
They are the reactive equivalent of the other REST clients.
@@ -401,19 +401,19 @@ Spring Data includes repository support for Elasticsearch.
As with the JPA repositories discussed earlier, the basic principle is that queries are constructed for you automatically based on method names.
In fact, both Spring Data JPA and Spring Data Elasticsearch share the same common infrastructure.
-You could take the JPA example from earlier and, assuming that `City` is now an Elasticsearch `@Document` class rather than a JPA `@Entity`, it works in the same way.
+You could take the JPA example from earlier and, assuming that `City` is now an Elasticsearch javadoc:org.springframework.data.elasticsearch.annotations.Document[format=annotation] class rather than a JPA javadoc:jakarta.persistence.Entity[format=annotation], it works in the same way.
Repositories and documents are found through scanning.
By default, the xref:using/auto-configuration.adoc#using.auto-configuration.packages[auto-configuration packages] are scanned.
-You can customize the locations to look for repositories and documents by using `@EnableElasticsearchRepositories` and `@EntityScan` respectively.
+You can customize the locations to look for repositories and documents by using javadoc:org.springframework.data.elasticsearch.repository.config.EnableElasticsearchRepositories[format=annotation] and javadoc:org.springframework.boot.autoconfigure.domain.EntityScan[format=annotation] respectively.
TIP: For complete details of Spring Data Elasticsearch, see the {url-spring-data-elasticsearch-docs}[reference documentation].
-Spring Boot supports both classic and reactive Elasticsearch repositories, using the `ElasticsearchTemplate` or `ReactiveElasticsearchTemplate` beans.
+Spring Boot supports both classic and reactive Elasticsearch repositories, using the javadoc:org.springframework.data.elasticsearch.client.elc.ElasticsearchTemplate[] or javadoc:org.springframework.data.elasticsearch.client.elc.ReactiveElasticsearchTemplate[] beans.
Most likely those beans are auto-configured by Spring Boot given the required dependencies are present.
-If you wish to use your own template for backing the Elasticsearch repositories, you can add your own `ElasticsearchTemplate` or `ElasticsearchOperations` `@Bean`, as long as it is named `"elasticsearchTemplate"`.
-Same applies to `ReactiveElasticsearchTemplate` and `ReactiveElasticsearchOperations`, with the bean name `"reactiveElasticsearchTemplate"`.
+If you wish to use your own template for backing the Elasticsearch repositories, you can add your own javadoc:org.springframework.data.elasticsearch.client.elc.ElasticsearchTemplate[] or javadoc:org.springframework.data.elasticsearch.core.ElasticsearchOperations[] javadoc:org.springframework.context.annotation.Bean[format=annotation], as long as it is named `"elasticsearchTemplate"`.
+Same applies to javadoc:org.springframework.data.elasticsearch.client.elc.ReactiveElasticsearchTemplate[] and javadoc:org.springframework.data.elasticsearch.core.ReactiveElasticsearchOperations[], with the bean name `"reactiveElasticsearchTemplate"`.
You can choose to disable the repositories support with the following property:
@@ -440,7 +440,7 @@ There is a `spring-boot-starter-data-cassandra` starter for collecting the depen
[[data.nosql.cassandra.connecting]]
=== Connecting to Cassandra
-You can inject an auto-configured `CassandraTemplate` or a Cassandra `CqlSession` instance as you would with any other Spring Bean.
+You can inject an auto-configured javadoc:org.springframework.data.cassandra.core.CassandraTemplate[] or a Cassandra `CqlSession` instance as you would with any other Spring Bean.
The `spring.cassandra.*` properties can be used to customize the connection.
Generally, you provide `keyspace-name` and `contact-points` as well the local datacenter name, as shown in the following example:
@@ -501,8 +501,8 @@ The Cassandra driver has its own configuration infrastructure that loads an `app
Spring Boot does not look for such a file by default but can load one using `spring.cassandra.config`.
If a property is both present in `+spring.cassandra.*+` and the configuration file, the value in `+spring.cassandra.*+` takes precedence.
-For more advanced driver customizations, you can register an arbitrary number of beans that implement `DriverConfigLoaderBuilderCustomizer`.
-The `CqlSession` can be customized with a bean of type `CqlSessionBuilderCustomizer`.
+For more advanced driver customizations, you can register an arbitrary number of beans that implement javadoc:org.springframework.boot.autoconfigure.cassandra.DriverConfigLoaderBuilderCustomizer[].
+The `CqlSession` can be customized with a bean of type javadoc:org.springframework.boot.autoconfigure.cassandra.CqlSessionBuilderCustomizer[].
====
NOTE: If you use `CqlSessionBuilder` to create multiple `CqlSession` beans, keep in mind the builder is mutable so make sure to inject a fresh copy for each session.
@@ -511,7 +511,7 @@ The following code listing shows how to inject a Cassandra bean:
include-code::MyBean[]
-If you add your own `@Bean` of type `CassandraTemplate`, it replaces the default.
+If you add your own javadoc:org.springframework.context.annotation.Bean[format=annotation] of type javadoc:org.springframework.data.cassandra.core.CassandraTemplate[], it replaces the default.
@@ -519,11 +519,11 @@ If you add your own `@Bean` of type `CassandraTemplate`, it replaces the default
=== Spring Data Cassandra Repositories
Spring Data includes basic repository support for Cassandra.
-Currently, this is more limited than the JPA repositories discussed earlier and needs `@Query` annotated finder methods.
+Currently, this is more limited than the JPA repositories discussed earlier and needs javadoc:org.springframework.data.cassandra.repository.Query[format=annotation] annotated finder methods.
Repositories and entities are found through scanning.
By default, the xref:using/auto-configuration.adoc#using.auto-configuration.packages[auto-configuration packages] are scanned.
-You can customize the locations to look for repositories and entities by using `@EnableCassandraRepositories` and `@EntityScan` respectively.
+You can customize the locations to look for repositories and entities by using javadoc:org.springframework.data.cassandra.repository.config.EnableCassandraRepositories[format=annotation] and javadoc:org.springframework.boot.autoconfigure.domain.EntityScan[format=annotation] respectively.
TIP: For complete details of Spring Data Cassandra, see the {url-spring-data-cassandra-docs}[reference documentation].
@@ -541,7 +541,7 @@ There are `spring-boot-starter-data-couchbase` and `spring-boot-starter-data-cou
[[data.nosql.couchbase.connecting]]
=== Connecting to Couchbase
-You can get a `Cluster` by adding the Couchbase SDK and some configuration.
+You can get a javadoc:com.couchbase.client.java.Cluster[] by adding the Couchbase SDK and some configuration.
The `spring.couchbase.*` properties can be used to customize the connection.
Generally, you provide the https://github.com/couchbaselabs/sdk-rfcs/blob/master/rfc/0011-connection-string.md[connection string], username, and password, as shown in the following example:
@@ -554,8 +554,8 @@ spring:
password: "secret"
----
-It is also possible to customize some of the `ClusterEnvironment` settings.
-For instance, the following configuration changes the timeout to open a new `Bucket` and enables SSL support with a reference to a configured xref:features/ssl.adoc[SSL bundle]:
+It is also possible to customize some of the javadoc:com.couchbase.client.java.env.ClusterEnvironment[] settings.
+For instance, the following configuration changes the timeout to open a new javadoc:com.couchbase.client.java.Bucket[] and enables SSL support with a reference to a configured xref:features/ssl.adoc[SSL bundle]:
[configprops,yaml]
----
@@ -569,7 +569,7 @@ spring:
----
TIP: Check the `spring.couchbase.env.*` properties for more details.
-To take more control, one or more `ClusterEnvironmentBuilderCustomizer` beans can be used.
+To take more control, one or more javadoc:org.springframework.boot.autoconfigure.couchbase.ClusterEnvironmentBuilderCustomizer[] beans can be used.
@@ -580,12 +580,12 @@ Spring Data includes repository support for Couchbase.
Repositories and documents are found through scanning.
By default, the xref:using/auto-configuration.adoc#using.auto-configuration.packages[auto-configuration packages] are scanned.
-You can customize the locations to look for repositories and documents by using `@EnableCouchbaseRepositories` and `@EntityScan` respectively.
+You can customize the locations to look for repositories and documents by using javadoc:org.springframework.data.couchbase.repository.config.EnableCouchbaseRepositories[format=annotation] and javadoc:org.springframework.boot.autoconfigure.domain.EntityScan[format=annotation] respectively.
For complete details of Spring Data Couchbase, see the {url-spring-data-couchbase-docs}[reference documentation].
-You can inject an auto-configured `CouchbaseTemplate` instance as you would with any other Spring Bean, provided a `CouchbaseClientFactory` bean is available.
-This happens when a `Cluster` is available, as described above, and a bucket name has been specified:
+You can inject an auto-configured javadoc:org.springframework.data.couchbase.core.CouchbaseTemplate[] instance as you would with any other Spring Bean, provided a javadoc:org.springframework.data.couchbase.CouchbaseClientFactory[] bean is available.
+This happens when a javadoc:com.couchbase.client.java.Cluster[] is available, as described above, and a bucket name has been specified:
[configprops,yaml]
----
@@ -595,17 +595,17 @@ spring:
bucket-name: "my-bucket"
----
-The following examples shows how to inject a `CouchbaseTemplate` bean:
+The following examples shows how to inject a javadoc:org.springframework.data.couchbase.core.CouchbaseTemplate[] bean:
include-code::MyBean[]
There are a few beans that you can define in your own configuration to override those provided by the auto-configuration:
-* A `CouchbaseMappingContext` `@Bean` with a name of `couchbaseMappingContext`.
-* A `CustomConversions` `@Bean` with a name of `couchbaseCustomConversions`.
-* A `CouchbaseTemplate` `@Bean` with a name of `couchbaseTemplate`.
+* A javadoc:org.springframework.data.couchbase.core.mapping.CouchbaseMappingContext[] javadoc:org.springframework.context.annotation.Bean[format=annotation] with a name of `couchbaseMappingContext`.
+* A javadoc:org.springframework.data.convert.CustomConversions[] javadoc:org.springframework.context.annotation.Bean[format=annotation] with a name of `couchbaseCustomConversions`.
+* A javadoc:org.springframework.data.couchbase.core.CouchbaseTemplate[] javadoc:org.springframework.context.annotation.Bean[format=annotation] with a name of `couchbaseTemplate`.
-To avoid hard-coding those names in your own config, you can reuse `BeanNames` provided by Spring Data Couchbase.
+To avoid hard-coding those names in your own config, you can reuse javadoc:org.springframework.data.couchbase.config.BeanNames[] provided by Spring Data Couchbase.
For instance, you can customize the converters to use, as follows:
include-code::MyCouchbaseConfiguration[]
@@ -639,10 +639,10 @@ spring:
If you need to customize connection settings, you can use the `spring.ldap.base` and `spring.ldap.base-environment` properties.
-An `LdapContextSource` is auto-configured based on these settings.
-If a `DirContextAuthenticationStrategy` bean is available, it is associated to the auto-configured `LdapContextSource`.
-If you need to customize it, for instance to use a `PooledContextSource`, you can still inject the auto-configured `LdapContextSource`.
-Make sure to flag your customized `ContextSource` as `@Primary` so that the auto-configured `LdapTemplate` uses it.
+An javadoc:org.springframework.ldap.core.support.LdapContextSource[] is auto-configured based on these settings.
+If a javadoc:org.springframework.ldap.core.support.DirContextAuthenticationStrategy[] bean is available, it is associated to the auto-configured javadoc:org.springframework.ldap.core.support.LdapContextSource[].
+If you need to customize it, for instance to use a javadoc:org.springframework.ldap.pool2.factory.PooledContextSource[], you can still inject the auto-configured javadoc:org.springframework.ldap.core.support.LdapContextSource[].
+Make sure to flag your customized javadoc:org.springframework.ldap.core.ContextSource[] as javadoc:org.springframework.context.annotation.Primary[format=annotation] so that the auto-configured javadoc:org.springframework.ldap.core.LdapTemplate[] uses it.
@@ -653,11 +653,11 @@ Spring Data includes repository support for LDAP.
Repositories and documents are found through scanning.
By default, the xref:using/auto-configuration.adoc#using.auto-configuration.packages[auto-configuration packages] are scanned.
-You can customize the locations to look for repositories and documents by using `@EnableLdapRepositories` and `@EntityScan` respectively.
+You can customize the locations to look for repositories and documents by using javadoc:org.springframework.data.ldap.repository.config.EnableLdapRepositories[format=annotation] and javadoc:org.springframework.boot.autoconfigure.domain.EntityScan[format=annotation] respectively.
TIP: For complete details of Spring Data LDAP, see the {url-spring-data-ldap-docs}[reference documentation].
-You can also inject an auto-configured `LdapTemplate` instance as you would with any other Spring Bean, as shown in the following example:
+You can also inject an auto-configured javadoc:org.springframework.ldap.core.LdapTemplate[] instance as you would with any other Spring Bean, as shown in the following example:
include-code::MyBean[]
@@ -716,11 +716,11 @@ https://www.influxdata.com/[InfluxDB] is an open-source time series database opt
[[data.nosql.influxdb.connecting]]
=== Connecting to InfluxDB
-Spring Boot auto-configures an `InfluxDB` instance, provided the `influxdb-java` client is on the classpath and the URL of the database is set using configprop:spring.influx.url[deprecated].
+Spring Boot auto-configures an javadoc:org.influxdb.InfluxDB[] instance, provided the `influxdb-java` client is on the classpath and the URL of the database is set using configprop:spring.influx.url[deprecated].
If the connection to InfluxDB requires a user and password, you can set the configprop:spring.influx.user[deprecated] and configprop:spring.influx.password[deprecated] properties accordingly.
InfluxDB relies on OkHttp.
-If you need to tune the http client `InfluxDB` uses behind the scenes, you can register an `InfluxDbOkHttpClientBuilderProvider` bean.
+If you need to tune the http client javadoc:org.influxdb.InfluxDB[] uses behind the scenes, you can register an javadoc:org.springframework.boot.autoconfigure.influx.InfluxDbOkHttpClientBuilderProvider[] bean.
-If you need more control over the configuration, consider registering an `InfluxDbCustomizer` bean.
+If you need more control over the configuration, consider registering an javadoc:org.springframework.boot.autoconfigure.influx.InfluxDbCustomizer[] bean.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/data/sql.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/data/sql.adoc
index d0840bd2e9..01f36930a8 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/data/sql.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/data/sql.adoc
@@ -1,16 +1,16 @@
[[data.sql]]
= SQL Databases
-The {url-spring-framework-site}[Spring Framework] provides extensive support for working with SQL databases, from direct JDBC access using `JdbcClient` or `JdbcTemplate` to complete "`object relational mapping`" technologies such as Hibernate.
-{url-spring-data-site}[Spring Data] provides an additional level of functionality: creating `Repository` implementations directly from interfaces and using conventions to generate queries from your method names.
+The {url-spring-framework-site}[Spring Framework] provides extensive support for working with SQL databases, from direct JDBC access using javadoc:org.springframework.jdbc.core.simple.JdbcClient[] or javadoc:org.springframework.jdbc.core.JdbcTemplate[] to complete "`object relational mapping`" technologies such as Hibernate.
+{url-spring-data-site}[Spring Data] provides an additional level of functionality: creating javadoc:org.springframework.data.repository.Repository[] implementations directly from interfaces and using conventions to generate queries from your method names.
[[data.sql.datasource]]
== Configure a DataSource
-Java's `javax.sql.DataSource` interface provides a standard method of working with database connections.
-Traditionally, a `DataSource` uses a `URL` along with some credentials to establish a database connection.
+Java's javadoc:javax.sql.DataSource[] interface provides a standard method of working with database connections.
+Traditionally, a javadoc:javax.sql.DataSource[] uses a `URL` along with some credentials to establish a database connection.
TIP: See the xref:how-to:data-access.adoc#howto.data-access.configure-custom-datasource[] section of the "`How-to Guides`" for more advanced examples, typically to take full control over the configuration of the DataSource.
@@ -65,7 +65,7 @@ Disabling the database's automatic shutdown lets Spring Boot control when the da
[[data.sql.datasource.production]]
=== Connection to a Production Database
-Production database connections can also be auto-configured by using a pooling `DataSource`.
+Production database connections can also be auto-configured by using a pooling javadoc:javax.sql.DataSource[].
@@ -90,7 +90,7 @@ Otherwise, Spring Boot tries to auto-configure an embedded database.
TIP: Spring Boot can deduce the JDBC driver class for most databases from the URL.
If you need to specify a specific class, you can use the configprop:spring.datasource.driver-class-name[] property.
-NOTE: For a pooling `DataSource` to be created, we need to be able to verify that a valid `Driver` class is available, so we check for that before doing anything.
+NOTE: For a pooling javadoc:javax.sql.DataSource[] to be created, we need to be able to verify that a valid javadoc:java.sql.Driver[] class is available, so we check for that before doing anything.
In other words, if you set `spring.datasource.driver-class-name=com.mysql.jdbc.Driver`, then that class has to be loadable.
See javadoc:org.springframework.boot.autoconfigure.jdbc.DataSourceProperties[] API documentation for more of the supported options.
@@ -121,7 +121,7 @@ Spring Boot uses the following algorithm for choosing a specific implementation:
. We prefer https://github.com/brettwooldridge/HikariCP[HikariCP] for its performance and concurrency.
If HikariCP is available, we always choose it.
-. Otherwise, if the Tomcat pooling `DataSource` is available, we use it.
+. Otherwise, if the Tomcat pooling javadoc:javax.sql.DataSource[] is available, we use it.
. Otherwise, if https://commons.apache.org/proper/commons-dbcp/[Commons DBCP2] is available, we use it.
. If none of HikariCP, Tomcat, and DBCP2 are available and if Oracle UCP is available, we use it.
@@ -130,17 +130,17 @@ NOTE: If you use the `spring-boot-starter-jdbc` or `spring-boot-starter-data-jpa
You can bypass that algorithm completely and specify the connection pool to use by setting the configprop:spring.datasource.type[] property.
This is especially important if you run your application in a Tomcat container, as `tomcat-jdbc` is provided by default.
-Additional connection pools can always be configured manually, using `DataSourceBuilder`.
-If you define your own `DataSource` bean, auto-configuration does not occur.
-The following connection pools are supported by `DataSourceBuilder`:
+Additional connection pools can always be configured manually, using javadoc:org.springframework.boot.jdbc.DataSourceBuilder[].
+If you define your own javadoc:javax.sql.DataSource[] bean, auto-configuration does not occur.
+The following connection pools are supported by javadoc:org.springframework.boot.jdbc.DataSourceBuilder[]:
* HikariCP
-* Tomcat pooling `DataSource`
+* Tomcat pooling javadoc:javax.sql.DataSource[]
* Commons DBCP2
* Oracle UCP & `OracleDataSource`
-* Spring Framework's `SimpleDriverDataSource`
-* H2 `JdbcDataSource`
-* PostgreSQL `PGSimpleDataSource`
+* Spring Framework's javadoc:org.springframework.jdbc.datasource.SimpleDriverDataSource[]
+* H2 javadoc:org.h2.jdbcx.JdbcDataSource[]
+* PostgreSQL javadoc:org.postgresql.ds.PGSimpleDataSource[]
* C3P0
@@ -150,8 +150,8 @@ The following connection pools are supported by `DataSourceBuilder`:
If you deploy your Spring Boot application to an Application Server, you might want to configure and manage your DataSource by using your Application Server's built-in features and access it by using JNDI.
-The configprop:spring.datasource.jndi-name[] property can be used as an alternative to the configprop:spring.datasource.url[], configprop:spring.datasource.username[], and configprop:spring.datasource.password[] properties to access the `DataSource` from a specific JNDI location.
-For example, the following section in `application.properties` shows how you can access a JBoss AS defined `DataSource`:
+The configprop:spring.datasource.jndi-name[] property can be used as an alternative to the configprop:spring.datasource.url[], configprop:spring.datasource.username[], and configprop:spring.datasource.password[] properties to access the javadoc:javax.sql.DataSource[] from a specific JNDI location.
+For example, the following section in `application.properties` shows how you can access a JBoss AS defined javadoc:javax.sql.DataSource[]:
[configprops,yaml]
----
@@ -165,7 +165,7 @@ spring:
[[data.sql.jdbc-template]]
== Using JdbcTemplate
-Spring's `JdbcTemplate` and `NamedParameterJdbcTemplate` classes are auto-configured, and you can autowire them directly into your own beans, as shown in the following example:
+Spring's javadoc:org.springframework.jdbc.core.JdbcTemplate[] and javadoc:org.springframework.jdbc.core.namedparam.NamedParameterJdbcTemplate[] classes are auto-configured, and you can autowire them directly into your own beans, as shown in the following example:
include-code::MyBean[]
@@ -179,20 +179,20 @@ spring:
max-rows: 500
----
-NOTE: The `NamedParameterJdbcTemplate` reuses the same `JdbcTemplate` instance behind the scenes.
-If more than one `JdbcTemplate` is defined and no primary candidate exists, the `NamedParameterJdbcTemplate` is not auto-configured.
+NOTE: The javadoc:org.springframework.jdbc.core.namedparam.NamedParameterJdbcTemplate[] reuses the same javadoc:org.springframework.jdbc.core.JdbcTemplate[] instance behind the scenes.
+If more than one javadoc:org.springframework.jdbc.core.JdbcTemplate[] is defined and no primary candidate exists, the javadoc:org.springframework.jdbc.core.namedparam.NamedParameterJdbcTemplate[] is not auto-configured.
[[data.sql.jdbc-client]]
== Using JdbcClient
-Spring's `JdbcClient` is auto-configured based on the presence of a `NamedParameterJdbcTemplate`.
+Spring's javadoc:org.springframework.jdbc.core.simple.JdbcClient[] is auto-configured based on the presence of a javadoc:org.springframework.jdbc.core.namedparam.NamedParameterJdbcTemplate[].
You can inject it directly in your own beans as well, as shown in the following example:
include-code::MyBean[]
-If you rely on auto-configuration to create the underlying `JdbcTemplate`, any customization using `spring.jdbc.template.*` properties is taken into account in the client as well.
+If you rely on auto-configuration to create the underlying javadoc:org.springframework.jdbc.core.JdbcTemplate[], any customization using `spring.jdbc.template.*` properties is taken into account in the client as well.
@@ -219,12 +219,12 @@ Traditionally, JPA "`Entity`" classes are specified in a `persistence.xml` file.
With Spring Boot, this file is not necessary and "`Entity Scanning`" is used instead.
By default the xref:using/auto-configuration.adoc#using.auto-configuration.packages[auto-configuration packages] are scanned.
-Any classes annotated with `@Entity`, `@Embeddable`, or `@MappedSuperclass` are considered.
+Any classes annotated with javadoc:jakarta.persistence.Entity[format=annotation], javadoc:jakarta.persistence.Embeddable[format=annotation], or javadoc:jakarta.persistence.MappedSuperclass[format=annotation] are considered.
A typical entity class resembles the following example:
include-code::City[]
-TIP: You can customize entity scanning locations by using the `@EntityScan` annotation.
+TIP: You can customize entity scanning locations by using the javadoc:org.springframework.boot.autoconfigure.domain.EntityScan[format=annotation] annotation.
See the xref:how-to:data-access.adoc#howto.data-access.separate-entity-definitions-from-spring-configuration[] section of the "`How-to Guides`".
@@ -241,7 +241,7 @@ For more complex queries, you can annotate your method with Spring Data's javado
Spring Data repositories usually extend from the javadoc:{url-spring-data-commons-javadoc}/org.springframework.data.repository.Repository[] or javadoc:{url-spring-data-commons-javadoc}/org.springframework.data.repository.CrudRepository[] interfaces.
If you use auto-configuration, the xref:using/auto-configuration.adoc#using.auto-configuration.packages[auto-configuration packages] are searched for repositories.
-TIP: You can customize the locations to look for repositories using `@EnableJpaRepositories`.
+TIP: You can customize the locations to look for repositories using javadoc:org.springframework.data.jpa.repository.config.EnableJpaRepositories[format=annotation].
The following example shows a typical Spring Data repository interface definition:
@@ -249,14 +249,14 @@ include-code::CityRepository[]
Spring Data JPA repositories support three different modes of bootstrapping: default, deferred, and lazy.
To enable deferred or lazy bootstrapping, set the configprop:spring.data.jpa.repositories.bootstrap-mode[] property to `deferred` or `lazy` respectively.
-When using deferred or lazy bootstrapping, the auto-configured `EntityManagerFactoryBuilder` will use the context's `AsyncTaskExecutor`, if any, as the bootstrap executor.
+When using deferred or lazy bootstrapping, the auto-configured javadoc:org.springframework.boot.orm.jpa.EntityManagerFactoryBuilder[] will use the context's javadoc:org.springframework.core.task.AsyncTaskExecutor[], if any, as the bootstrap executor.
If more than one exists, the one named `applicationTaskExecutor` will be used.
[NOTE]
====
When using deferred or lazy bootstrapping, make sure to defer any access to the JPA infrastructure after the application context bootstrap phase.
-You can use `SmartInitializingSingleton` to invoke any initialization that requires the JPA infrastructure.
-For JPA components (such as converters) that are created as Spring beans, use `ObjectProvider` to delay the resolution of dependencies, if any.
+You can use javadoc:org.springframework.beans.factory.SmartInitializingSingleton[] to invoke any initialization that requires the JPA infrastructure.
+For JPA components (such as converters) that are created as Spring beans, use javadoc:org.springframework.beans.factory.ObjectProvider[] to delay the resolution of dependencies, if any.
====
TIP: We have barely scratched the surface of Spring Data JPA.
@@ -269,7 +269,7 @@ For complete details, see the {url-spring-data-jpa-docs}[Spring Data JPA referen
If {url-spring-data-envers-site}[Spring Data Envers] is available, JPA repositories are auto-configured to support typical Envers queries.
-To use Spring Data Envers, make sure your repository extends from `RevisionRepository` as shown in the following example:
+To use Spring Data Envers, make sure your repository extends from javadoc:org.springframework.data.repository.history.RevisionRepository[] as shown in the following example:
include-code::CountryRepository[]
@@ -306,7 +306,7 @@ spring:
The line in the preceding example passes a value of `true` for the `hibernate.globally_quoted_identifiers` property to the Hibernate entity manager.
-By default, the DDL execution (or validation) is deferred until the `ApplicationContext` has started.
+By default, the DDL execution (or validation) is deferred until the javadoc:org.springframework.context.ApplicationContext[] has started.
@@ -321,12 +321,12 @@ If you do not want this behavior, you should set `spring.jpa.open-in-view` to `f
[[data.sql.jdbc]]
== Spring Data JDBC
-Spring Data includes repository support for JDBC and will automatically generate SQL for the methods on `CrudRepository`.
-For more advanced queries, a `@Query` annotation is provided.
+Spring Data includes repository support for JDBC and will automatically generate SQL for the methods on javadoc:org.springframework.data.repository.CrudRepository[].
+For more advanced queries, a javadoc:org.springframework.data.jdbc.repository.query.Query[format=annotation] annotation is provided.
Spring Boot will auto-configure Spring Data's JDBC repositories when the necessary dependencies are on the classpath.
They can be added to your project with a single dependency on `spring-boot-starter-data-jdbc`.
-If necessary, you can take control of Spring Data JDBC's configuration by adding the `@EnableJdbcRepositories` annotation or an `AbstractJdbcConfiguration` subclass to your application.
+If necessary, you can take control of Spring Data JDBC's configuration by adding the javadoc:org.springframework.data.jdbc.repository.config.EnableJdbcRepositories[format=annotation] annotation or an javadoc:org.springframework.data.jdbc.repository.config.AbstractJdbcConfiguration[] subclass to your application.
TIP: For complete details of Spring Data JDBC, see the {url-spring-data-jdbc-docs}[reference documentation].
@@ -367,7 +367,7 @@ If your application uses Spring Security, you need to configure it to
More information on {url-spring-security-docs}/features/exploits/csrf.html[CSRF] and the header {url-spring-security-docs}/features/exploits/headers.html#headers-frame-options[X-Frame-Options] can be found in the Spring Security Reference Guide.
-In simple setups, a `SecurityFilterChain` like the following can be used:
+In simple setups, a javadoc:org.springframework.security.web.SecurityFilterChain[] like the following can be used:
include-code::DevProfileSecurityConfiguration[tag=!customizer]
@@ -427,15 +427,15 @@ The following listing shows an example:
[[data.sql.jooq.dslcontext]]
=== Using DSLContext
-The fluent API offered by jOOQ is initiated through the `org.jooq.DSLContext` interface.
-Spring Boot auto-configures a `DSLContext` as a Spring Bean and connects it to your application `DataSource`.
-To use the `DSLContext`, you can inject it, as shown in the following example:
+The fluent API offered by jOOQ is initiated through the javadoc:org.jooq.DSLContext[] interface.
+Spring Boot auto-configures a javadoc:org.jooq.DSLContext[] as a Spring Bean and connects it to your application javadoc:javax.sql.DataSource[].
+To use the javadoc:org.jooq.DSLContext[], you can inject it, as shown in the following example:
include-code::MyBean[tag=!method]
-TIP: The jOOQ manual tends to use a variable named `create` to hold the `DSLContext`.
+TIP: The jOOQ manual tends to use a variable named `create` to hold the javadoc:org.jooq.DSLContext[].
-You can then use the `DSLContext` to construct your queries, as shown in the following example:
+You can then use the javadoc:org.jooq.DSLContext[] to construct your queries, as shown in the following example:
include-code::MyBean[tag=method]
@@ -454,10 +454,10 @@ NOTE: Spring Boot can only auto-configure dialects supported by the open source
[[data.sql.jooq.customizing]]
=== Customizing jOOQ
-More advanced customizations can be achieved by defining your own `DefaultConfigurationCustomizer` bean that will be invoked prior to creating the `org.jooq.Configuration` `@Bean`.
+More advanced customizations can be achieved by defining your own javadoc:org.springframework.boot.autoconfigure.jooq.DefaultConfigurationCustomizer[] bean that will be invoked prior to creating the javadoc:org.jooq.Configuration[] javadoc:org.springframework.context.annotation.Bean[format=annotation].
This takes precedence to anything that is applied by the auto-configuration.
-You can also create your own `org.jooq.Configuration` `@Bean` if you want to take complete control of the jOOQ configuration.
+You can also create your own javadoc:org.jooq.Configuration[] javadoc:org.springframework.context.annotation.Bean[format=annotation] if you want to take complete control of the jOOQ configuration.
@@ -465,10 +465,10 @@ You can also create your own `org.jooq.Configuration` `@Bean` if you want to tak
== Using R2DBC
The Reactive Relational Database Connectivity (https://r2dbc.io[R2DBC]) project brings reactive programming APIs to relational databases.
-R2DBC's `io.r2dbc.spi.Connection` provides a standard method of working with non-blocking database connections.
-Connections are provided by using a `ConnectionFactory`, similar to a `DataSource` with jdbc.
+R2DBC's javadoc:io.r2dbc.spi.Connection[] provides a standard method of working with non-blocking database connections.
+Connections are provided by using a javadoc:io.r2dbc.spi.ConnectionFactory[], similar to a javadoc:javax.sql.DataSource[] with jdbc.
-`ConnectionFactory` configuration is controlled by external configuration properties in `+spring.r2dbc.*+`.
+javadoc:io.r2dbc.spi.ConnectionFactory[] configuration is controlled by external configuration properties in `+spring.r2dbc.*+`.
For example, you might declare the following section in `application.properties`:
[configprops,yaml]
@@ -487,7 +487,7 @@ Information specified in the URL takes precedence over individual properties, th
TIP: The "`How-to Guides`" section includes a xref:how-to:data-initialization.adoc#howto.data-initialization.using-basic-sql-scripts[section on how to initialize a database].
-To customize the connections created by a `ConnectionFactory`, that is, set specific parameters that you do not want (or cannot) configure in your central database configuration, you can use a `ConnectionFactoryOptionsBuilderCustomizer` `@Bean`.
+To customize the connections created by a javadoc:io.r2dbc.spi.ConnectionFactory[], that is, set specific parameters that you do not want (or cannot) configure in your central database configuration, you can use a javadoc:org.springframework.boot.autoconfigure.r2dbc.ConnectionFactoryOptionsBuilderCustomizer[] javadoc:org.springframework.context.annotation.Bean[format=annotation].
The following example shows how to manually override the database port while the rest of the options are taken from the application configuration:
include-code::MyR2dbcConfiguration[]
@@ -496,8 +496,8 @@ The following examples show how to set some PostgreSQL connection options:
include-code::MyPostgresR2dbcConfiguration[]
-When a `ConnectionFactory` bean is available, the regular JDBC `DataSource` auto-configuration backs off.
-If you want to retain the JDBC `DataSource` auto-configuration, and are comfortable with the risk of using the blocking JDBC API in a reactive application, add `@Import(DataSourceAutoConfiguration.class)` on a `@Configuration` class in your application to re-enable it.
+When a javadoc:io.r2dbc.spi.ConnectionFactory[] bean is available, the regular JDBC javadoc:javax.sql.DataSource[] auto-configuration backs off.
+If you want to retain the JDBC javadoc:javax.sql.DataSource[] auto-configuration, and are comfortable with the risk of using the blocking JDBC API in a reactive application, add `@Import(DataSourceAutoConfiguration.class)` on a javadoc:org.springframework.context.annotation.Configuration[format=annotation] class in your application to re-enable it.
@@ -528,7 +528,7 @@ If you want to make sure that each context has a separate embedded database, you
[[data.sql.r2dbc.using-database-client]]
=== Using DatabaseClient
-A `DatabaseClient` bean is auto-configured, and you can autowire it directly into your own beans, as shown in the following example:
+A javadoc:org.springframework.r2dbc.core.DatabaseClient[] bean is auto-configured, and you can autowire it directly into your own beans, as shown in the following example:
include-code::MyBean[]
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/aop.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/aop.adoc
index a43bb64898..cc26b17f57 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/aop.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/aop.adoc
@@ -7,4 +7,4 @@ You can learn more about AOP with Spring in the {url-spring-framework-docs}/core
By default, Spring Boot's auto-configuration configures Spring AOP to use CGLib proxies.
To use JDK proxies instead, set configprop:spring.aop.proxy-target-class[] to `false`.
-If AspectJ is on the classpath, Spring Boot's auto-configuration will automatically enable AspectJ auto proxy such that `@EnableAspectJAutoProxy` is not required.
+If AspectJ is on the classpath, Spring Boot's auto-configuration will automatically enable AspectJ auto proxy such that javadoc:org.springframework.context.annotation.EnableAspectJAutoProxy[format=annotation] is not required.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/dev-services.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/dev-services.adoc
index a977998ca6..ad3ae9609e 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/dev-services.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/dev-services.adoc
@@ -83,49 +83,49 @@ The following service connections are currently supported:
|===
| Connection Details | Matched on
-| `ActiveMQConnectionDetails`
+| javadoc:org.springframework.boot.autoconfigure.jms.activemq.ActiveMQConnectionDetails[]
| Containers named "symptoma/activemq" or "apache/activemq-classic"
-| `ArtemisConnectionDetails`
+| javadoc:org.springframework.boot.autoconfigure.jms.artemis.ArtemisConnectionDetails[]
| Containers named "apache/activemq-artemis"
-| `CassandraConnectionDetails`
+| javadoc:org.springframework.boot.autoconfigure.cassandra.CassandraConnectionDetails[]
| Containers named "cassandra" or "bitnami/cassandra"
-| `ElasticsearchConnectionDetails`
+| javadoc:org.springframework.boot.autoconfigure.elasticsearch.ElasticsearchConnectionDetails[]
| Containers named "elasticsearch" or "bitnami/elasticsearch"
-| `JdbcConnectionDetails`
+| javadoc:org.springframework.boot.autoconfigure.jdbc.JdbcConnectionDetails[]
| Containers named "gvenzl/oracle-free", "gvenzl/oracle-xe", "mariadb", "bitnami/mariadb", "mssql/server", "mysql", "bitnami/mysql", "postgres", or "bitnami/postgresql"
-| `LdapConnectionDetails`
+| javadoc:org.springframework.boot.autoconfigure.ldap.LdapConnectionDetails[]
| Containers named "osixia/openldap"
-| `MongoConnectionDetails`
+| javadoc:org.springframework.boot.autoconfigure.mongo.MongoConnectionDetails[]
| Containers named "mongo" or "bitnami/mongodb"
-| `Neo4jConnectionDetails`
+| javadoc:org.springframework.boot.autoconfigure.neo4j.Neo4jConnectionDetails[]
| Containers named "neo4j" or "bitnami/neo4j"
-| `OtlpMetricsConnectionDetails`
+| javadoc:org.springframework.boot.actuate.autoconfigure.metrics.export.otlp.OtlpMetricsConnectionDetails[]
| Containers named "otel/opentelemetry-collector-contrib"
-| `OtlpTracingConnectionDetails`
+| javadoc:org.springframework.boot.actuate.autoconfigure.tracing.otlp.OtlpTracingConnectionDetails[]
| Containers named "otel/opentelemetry-collector-contrib"
-| `PulsarConnectionDetails`
+| javadoc:org.springframework.boot.autoconfigure.pulsar.PulsarConnectionDetails[]
| Containers named "apachepulsar/pulsar"
-| `R2dbcConnectionDetails`
+| javadoc:org.springframework.boot.autoconfigure.r2dbc.R2dbcConnectionDetails[]
| Containers named "gvenzl/oracle-free", "gvenzl/oracle-xe", "mariadb", "bitnami/mariadb", "mssql/server", "mysql", "bitnami/mysql", "postgres", or "bitnami/postgresql"
-| `RabbitConnectionDetails`
+| javadoc:org.springframework.boot.autoconfigure.amqp.RabbitConnectionDetails[]
| Containers named "rabbitmq" or "bitnami/rabbitmq"
-| `RedisConnectionDetails`
+| javadoc:org.springframework.boot.autoconfigure.data.redis.RedisConnectionDetails[]
| Containers named "redis" or "bitnami/redis"
-| `ZipkinConnectionDetails`
+| javadoc:org.springframework.boot.actuate.autoconfigure.tracing.zipkin.ZipkinConnectionDetails[]
| Containers named "openzipkin/zipkin".
|===
@@ -328,18 +328,18 @@ The `TestMyApplication` class can use the `SpringApplication.from(...)` method t
include-code::launch/TestMyApplication[]
-You'll also need to define the `Container` instances that you want to start along with your application.
+You'll also need to define the javadoc:org.testcontainers.containers.Container[] instances that you want to start along with your application.
To do this, you need to make sure that the `spring-boot-testcontainers` module has been added as a `test` dependency.
-Once that has been done, you can create a `@TestConfiguration` class that declares `@Bean` methods for the containers you want to start.
+Once that has been done, you can create a javadoc:org.springframework.boot.test.context.TestConfiguration[format=annotation] class that declares javadoc:org.springframework.context.annotation.Bean[format=annotation] methods for the containers you want to start.
-You can also annotate your `@Bean` methods with `@ServiceConnection` in order to create `ConnectionDetails` beans.
+You can also annotate your javadoc:org.springframework.context.annotation.Bean[format=annotation] methods with javadoc:org.springframework.boot.testcontainers.service.connection.ServiceConnection[format=annotation] in order to create javadoc:org.springframework.boot.autoconfigure.service.connection.ConnectionDetails[] beans.
See xref:testing/testcontainers.adoc#testing.testcontainers.service-connections[the service connections] section for details of the supported technologies.
A typical Testcontainers configuration would look like this:
include-code::test/MyContainersConfiguration[]
-NOTE: The lifecycle of `Container` beans is automatically managed by Spring Boot.
+NOTE: The lifecycle of javadoc:org.testcontainers.containers.Container[] beans is automatically managed by Spring Boot.
Containers will be started and stopped automatically.
TIP: You can use the configprop:spring.testcontainers.beans.startup[] property to change how containers are started.
@@ -358,7 +358,7 @@ TIP: You can use the Maven goal `spring-boot:test-run` or the Gradle task `bootT
[[features.dev-services.testcontainers.at-development-time.dynamic-properties]]
==== Contributing Dynamic Properties at Development Time
-If you want to contribute dynamic properties at development time from your `Container` `@Bean` methods, you can do so by injecting a `DynamicPropertyRegistry`.
+If you want to contribute dynamic properties at development time from your javadoc:org.testcontainers.containers.Container[] javadoc:org.springframework.context.annotation.Bean[format=annotation] methods, you can do so by injecting a javadoc:org.springframework.test.context.DynamicPropertyRegistry[].
This works in a similar way to the xref:testing/testcontainers.adoc#testing.testcontainers.dynamic-properties[`@DynamicPropertySource` annotation] that you can use in your tests.
It allows you to add properties that will become available once your container has started.
@@ -366,14 +366,14 @@ A typical configuration would look like this:
include-code::MyContainersConfiguration[]
-NOTE: Using a `@ServiceConnection` is recommended whenever possible, however, dynamic properties can be a useful fallback for technologies that don't yet have `@ServiceConnection` support.
+NOTE: Using a javadoc:org.springframework.boot.testcontainers.service.connection.ServiceConnection[format=annotation] is recommended whenever possible, however, dynamic properties can be a useful fallback for technologies that don't yet have javadoc:org.springframework.boot.testcontainers.service.connection.ServiceConnection[format=annotation] support.
[[features.dev-services.testcontainers.at-development-time.importing-container-declarations]]
==== Importing Testcontainer Declaration Classes
-A common pattern when using Testcontainers is to declare `Container` instances as static fields.
+A common pattern when using Testcontainers is to declare javadoc:org.testcontainers.containers.Container[] instances as static fields.
Often these fields are defined directly on the test class.
They can also be declared on a parent class or on an interface that the test implements.
@@ -381,22 +381,22 @@ For example, the following `MyContainers` interface declares `mongo` and `neo4j`
include-code::MyContainers[]
-If you already have containers defined in this way, or you just prefer this style, you can import these declaration classes rather than defining your containers as `@Bean` methods.
-To do so, add the `@ImportTestcontainers` annotation to your test configuration class:
+If you already have containers defined in this way, or you just prefer this style, you can import these declaration classes rather than defining your containers as javadoc:org.springframework.context.annotation.Bean[format=annotation] methods.
+To do so, add the javadoc:org.springframework.boot.testcontainers.context.ImportTestcontainers[format=annotation] annotation to your test configuration class:
include-code::MyContainersConfiguration[]
-TIP: If you don't intend to use the xref:testing/testcontainers.adoc#testing.testcontainers.service-connections[service connections feature] but want to use xref:testing/testcontainers.adoc#testing.testcontainers.dynamic-properties[`@DynamicPropertySource`] instead, remove the `@ServiceConnection` annotation from the `Container` fields.
-You can also add `@DynamicPropertySource` annotated methods to your declaration class.
+TIP: If you don't intend to use the xref:testing/testcontainers.adoc#testing.testcontainers.service-connections[service connections feature] but want to use xref:testing/testcontainers.adoc#testing.testcontainers.dynamic-properties[`@DynamicPropertySource`] instead, remove the javadoc:org.springframework.boot.testcontainers.service.connection.ServiceConnection[format=annotation] annotation from the javadoc:org.testcontainers.containers.Container[] fields.
+You can also add javadoc:org.springframework.test.context.DynamicPropertySource[format=annotation] annotated methods to your declaration class.
[[features.dev-services.testcontainers.at-development-time.devtools]]
==== Using DevTools with Testcontainers at Development Time
-When using devtools, you can annotate beans and bean methods with `@RestartScope`.
+When using devtools, you can annotate beans and bean methods with javadoc:org.springframework.boot.devtools.restart.RestartScope[format=annotation].
Such beans won't be recreated when the devtools restart the application.
-This is especially useful for Testcontainer `Container` beans, as they keep their state despite the application restart.
+This is especially useful for Testcontainer javadoc:org.testcontainers.containers.Container[] beans, as they keep their state despite the application restart.
include-code::MyContainersConfiguration[]
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/developing-auto-configuration.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/developing-auto-configuration.adoc
index 50ed985160..07885f8e50 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/developing-auto-configuration.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/developing-auto-configuration.adoc
@@ -12,13 +12,13 @@ We first cover what you need to know to build your own auto-configuration and th
[[features.developing-auto-configuration.understanding-auto-configured-beans]]
== Understanding Auto-configured Beans
-Classes that implement auto-configuration are annotated with `@AutoConfiguration`.
-This annotation itself is meta-annotated with `@Configuration`, making auto-configurations standard `@Configuration` classes.
-Additional `@Conditional` annotations are used to constrain when the auto-configuration should apply.
-Usually, auto-configuration classes use `@ConditionalOnClass` and `@ConditionalOnMissingBean` annotations.
-This ensures that auto-configuration applies only when relevant classes are found and when you have not declared your own `@Configuration`.
+Classes that implement auto-configuration are annotated with javadoc:org.springframework.boot.autoconfigure.AutoConfiguration[format=annotation].
+This annotation itself is meta-annotated with javadoc:org.springframework.context.annotation.Configuration[format=annotation], making auto-configurations standard javadoc:org.springframework.context.annotation.Configuration[format=annotation] classes.
+Additional javadoc:org.springframework.context.annotation.Conditional[format=annotation] annotations are used to constrain when the auto-configuration should apply.
+Usually, auto-configuration classes use javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnClass[format=annotation] and javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean[format=annotation] annotations.
+This ensures that auto-configuration applies only when relevant classes are found and when you have not declared your own javadoc:org.springframework.context.annotation.Configuration[format=annotation].
-You can browse the source code of {code-spring-boot-autoconfigure-src}[`spring-boot-autoconfigure`] to see the `@AutoConfiguration` classes that Spring provides (see the {code-spring-boot}/spring-boot-project/spring-boot-autoconfigure/src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports[`META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports`] file).
+You can browse the source code of {code-spring-boot-autoconfigure-src}[`spring-boot-autoconfigure`] to see the javadoc:org.springframework.boot.autoconfigure.AutoConfiguration[format=annotation] classes that Spring provides (see the {code-spring-boot}/spring-boot-project/spring-boot-autoconfigure/src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports[`META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports`] file).
@@ -39,26 +39,26 @@ TIP: You can add comments to the imports file using the `#` character.
NOTE: Auto-configurations must be loaded _only_ by being named in the imports file.
Make sure that they are defined in a specific package space and that they are never the target of component scanning.
Furthermore, auto-configuration classes should not enable component scanning to find additional components.
-Specific `@Import` annotations should be used instead.
+Specific javadoc:org.springframework.context.annotation.Import[format=annotation] annotations should be used instead.
If your configuration needs to be applied in a specific order, you can use the `before`, `beforeName`, `after` and `afterName` attributes on the javadoc:org.springframework.boot.autoconfigure.AutoConfiguration[format=annotation] annotation or the dedicated javadoc:org.springframework.boot.autoconfigure.AutoConfigureBefore[format=annotation] and javadoc:org.springframework.boot.autoconfigure.AutoConfigureAfter[format=annotation] annotations.
-For example, if you provide web-specific configuration, your class may need to be applied after `WebMvcAutoConfiguration`.
+For example, if you provide web-specific configuration, your class may need to be applied after javadoc:org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration[].
-If you want to order certain auto-configurations that should not have any direct knowledge of each other, you can also use `@AutoConfigureOrder`.
-That annotation has the same semantic as the regular `@Order` annotation but provides a dedicated order for auto-configuration classes.
+If you want to order certain auto-configurations that should not have any direct knowledge of each other, you can also use javadoc:org.springframework.boot.autoconfigure.AutoConfigureOrder[format=annotation].
+That annotation has the same semantic as the regular javadoc:org.springframework.core.annotation.Order[format=annotation] annotation but provides a dedicated order for auto-configuration classes.
-As with standard `@Configuration` classes, the order in which auto-configuration classes are applied only affects the order in which their beans are defined.
-The order in which those beans are subsequently created is unaffected and is determined by each bean's dependencies and any `@DependsOn` relationships.
+As with standard javadoc:org.springframework.context.annotation.Configuration[format=annotation] classes, the order in which auto-configuration classes are applied only affects the order in which their beans are defined.
+The order in which those beans are subsequently created is unaffected and is determined by each bean's dependencies and any javadoc:org.springframework.context.annotation.DependsOn[format=annotation] relationships.
[[features.developing-auto-configuration.condition-annotations]]
== Condition Annotations
-You almost always want to include one or more `@Conditional` annotations on your auto-configuration class.
-The `@ConditionalOnMissingBean` annotation is one common example that is used to allow developers to override auto-configuration if they are not happy with your defaults.
+You almost always want to include one or more javadoc:org.springframework.context.annotation.Conditional[format=annotation] annotations on your auto-configuration class.
+The javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean[format=annotation] annotation is one common example that is used to allow developers to override auto-configuration if they are not happy with your defaults.
-Spring Boot includes a number of `@Conditional` annotations that you can reuse in your own code by annotating `@Configuration` classes or individual `@Bean` methods.
+Spring Boot includes a number of javadoc:org.springframework.context.annotation.Conditional[format=annotation] annotations that you can reuse in your own code by annotating javadoc:org.springframework.context.annotation.Configuration[format=annotation] classes or individual javadoc:org.springframework.context.annotation.Bean[format=annotation] methods.
These annotations include:
* xref:features/developing-auto-configuration.adoc#features.developing-auto-configuration.condition-annotations.class-conditions[]
@@ -73,49 +73,49 @@ These annotations include:
[[features.developing-auto-configuration.condition-annotations.class-conditions]]
=== Class Conditions
-The `@ConditionalOnClass` and `@ConditionalOnMissingClass` annotations let `@Configuration` classes be included based on the presence or absence of specific classes.
+The javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnClass[format=annotation] and javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnMissingClass[format=annotation] annotations let javadoc:org.springframework.context.annotation.Configuration[format=annotation] classes be included based on the presence or absence of specific classes.
Due to the fact that annotation metadata is parsed by using https://asm.ow2.io/[ASM], you can use the `value` attribute to refer to the real class, even though that class might not actually appear on the running application classpath.
-You can also use the `name` attribute if you prefer to specify the class name by using a `String` value.
+You can also use the `name` attribute if you prefer to specify the class name by using a javadoc:java.lang.String[] value.
-This mechanism does not apply the same way to `@Bean` methods where typically the return type is the target of the condition: before the condition on the method applies, the JVM will have loaded the class and potentially processed method references which will fail if the class is not present.
+This mechanism does not apply the same way to javadoc:org.springframework.context.annotation.Bean[format=annotation] methods where typically the return type is the target of the condition: before the condition on the method applies, the JVM will have loaded the class and potentially processed method references which will fail if the class is not present.
-To handle this scenario, a separate `@Configuration` class can be used to isolate the condition, as shown in the following example:
+To handle this scenario, a separate javadoc:org.springframework.context.annotation.Configuration[format=annotation] class can be used to isolate the condition, as shown in the following example:
include-code::MyAutoConfiguration[]
-TIP: If you use `@ConditionalOnClass` or `@ConditionalOnMissingClass` as a part of a meta-annotation to compose your own composed annotations, you must use `name` as referring to the class in such a case is not handled.
+TIP: If you use javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnClass[format=annotation] or javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnMissingClass[format=annotation] as a part of a meta-annotation to compose your own composed annotations, you must use `name` as referring to the class in such a case is not handled.
[[features.developing-auto-configuration.condition-annotations.bean-conditions]]
=== Bean Conditions
-The `@ConditionalOnBean` and `@ConditionalOnMissingBean` annotations let a bean be included based on the presence or absence of specific beans.
+The javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnBean[format=annotation] and javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean[format=annotation] annotations let a bean be included based on the presence or absence of specific beans.
You can use the `value` attribute to specify beans by type or `name` to specify beans by name.
-The `search` attribute lets you limit the `ApplicationContext` hierarchy that should be considered when searching for beans.
+The `search` attribute lets you limit the javadoc:org.springframework.context.ApplicationContext[] hierarchy that should be considered when searching for beans.
-When placed on a `@Bean` method, the target type defaults to the return type of the method, as shown in the following example:
+When placed on a javadoc:org.springframework.context.annotation.Bean[format=annotation] method, the target type defaults to the return type of the method, as shown in the following example:
include-code::MyAutoConfiguration[]
-In the preceding example, the `someService` bean is going to be created if no bean of type `SomeService` is already contained in the `ApplicationContext`.
+In the preceding example, the `someService` bean is going to be created if no bean of type `SomeService` is already contained in the javadoc:org.springframework.context.ApplicationContext[].
TIP: You need to be very careful about the order in which bean definitions are added, as these conditions are evaluated based on what has been processed so far.
-For this reason, we recommend using only `@ConditionalOnBean` and `@ConditionalOnMissingBean` annotations on auto-configuration classes (since these are guaranteed to load after any user-defined bean definitions have been added).
+For this reason, we recommend using only javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnBean[format=annotation] and javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean[format=annotation] annotations on auto-configuration classes (since these are guaranteed to load after any user-defined bean definitions have been added).
-NOTE: `@ConditionalOnBean` and `@ConditionalOnMissingBean` do not prevent `@Configuration` classes from being created.
-The only difference between using these conditions at the class level and marking each contained `@Bean` method with the annotation is that the former prevents registration of the `@Configuration` class as a bean if the condition does not match.
+NOTE: javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnBean[format=annotation] and javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean[format=annotation] do not prevent javadoc:org.springframework.context.annotation.Configuration[format=annotation] classes from being created.
+The only difference between using these conditions at the class level and marking each contained javadoc:org.springframework.context.annotation.Bean[format=annotation] method with the annotation is that the former prevents registration of the javadoc:org.springframework.context.annotation.Configuration[format=annotation] class as a bean if the condition does not match.
-TIP: When declaring a `@Bean` method, provide as much type information as possible in the method's return type.
+TIP: When declaring a javadoc:org.springframework.context.annotation.Bean[format=annotation] method, provide as much type information as possible in the method's return type.
For example, if your bean's concrete class implements an interface the bean method's return type should be the concrete class and not the interface.
-Providing as much type information as possible in `@Bean` methods is particularly important when using bean conditions as their evaluation can only rely upon to type information that is available in the method signature.
+Providing as much type information as possible in javadoc:org.springframework.context.annotation.Bean[format=annotation] methods is particularly important when using bean conditions as their evaluation can only rely upon to type information that is available in the method signature.
[[features.developing-auto-configuration.condition-annotations.property-conditions]]
=== Property Conditions
-The `@ConditionalOnProperty` annotation lets configuration be included based on a Spring Environment property.
+The javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnProperty[format=annotation] annotation lets configuration be included based on a Spring Environment property.
Use the `prefix` and `name` attributes to specify the property that should be checked.
By default, any property that exists and is not equal to `false` is matched.
You can also create more advanced checks by using the `havingValue` and `matchIfMissing` attributes.
@@ -127,7 +127,7 @@ If multiple names are given in the `name` attribute, all of the properties have
[[features.developing-auto-configuration.condition-annotations.resource-conditions]]
=== Resource Conditions
-The `@ConditionalOnResource` annotation lets configuration be included only when a specific resource is present.
+The javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnResource[format=annotation] annotation lets configuration be included only when a specific resource is present.
Resources can be specified by using the usual Spring conventions, as shown in the following example: `file:/home/user/test.dat`.
@@ -135,11 +135,11 @@ Resources can be specified by using the usual Spring conventions, as shown in th
[[features.developing-auto-configuration.condition-annotations.web-application-conditions]]
=== Web Application Conditions
-The `@ConditionalOnWebApplication` and `@ConditionalOnNotWebApplication` annotations let configuration be included depending on whether the application is a web application.
-A servlet-based web application is any application that uses a Spring `WebApplicationContext`, defines a `session` scope, or has a `ConfigurableWebEnvironment`.
-A reactive web application is any application that uses a `ReactiveWebApplicationContext`, or has a `ConfigurableReactiveWebEnvironment`.
+The javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnWebApplication[format=annotation] and javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnNotWebApplication[format=annotation] annotations let configuration be included depending on whether the application is a web application.
+A servlet-based web application is any application that uses a Spring javadoc:org.springframework.web.context.WebApplicationContext[], defines a `session` scope, or has a javadoc:org.springframework.web.context.ConfigurableWebEnvironment[].
+A reactive web application is any application that uses a javadoc:org.springframework.boot.web.reactive.context.ReactiveWebApplicationContext[], or has a javadoc:org.springframework.boot.web.reactive.context.ConfigurableReactiveWebEnvironment[].
-The `@ConditionalOnWarDeployment` and `@ConditionalOnNotWarDeployment` annotations let configuration be included depending on whether the application is a traditional WAR application that is deployed to a servlet container.
+The javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnWarDeployment[format=annotation] and javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnNotWarDeployment[format=annotation] annotations let configuration be included depending on whether the application is a traditional WAR application that is deployed to a servlet container.
This condition will not match for applications that are run with an embedded web server.
@@ -147,7 +147,7 @@ This condition will not match for applications that are run with an embedded web
[[features.developing-auto-configuration.condition-annotations.spel-conditions]]
=== SpEL Expression Conditions
-The `@ConditionalOnExpression` annotation lets configuration be included based on the result of a {url-spring-framework-docs}/core/expressions.html[SpEL expression].
+The javadoc:org.springframework.boot.autoconfigure.condition.ConditionalOnExpression[format=annotation] annotation lets configuration be included based on the result of a {url-spring-framework-docs}/core/expressions.html[SpEL expression].
NOTE: Referencing a bean in the expression will cause that bean to be initialized very early in context refresh processing.
As a result, the bean won't be eligible for post-processing (such as configuration properties binding) and its state may be incomplete.
@@ -157,13 +157,13 @@ As a result, the bean won't be eligible for post-processing (such as configurati
[[features.developing-auto-configuration.testing]]
== Testing your Auto-configuration
-An auto-configuration can be affected by many factors: user configuration (`@Bean` definition and `Environment` customization), condition evaluation (presence of a particular library), and others.
-Concretely, each test should create a well defined `ApplicationContext` that represents a combination of those customizations.
-`ApplicationContextRunner` provides a great way to achieve that.
+An auto-configuration can be affected by many factors: user configuration (`@Bean` definition and javadoc:org.springframework.core.env.Environment[] customization), condition evaluation (presence of a particular library), and others.
+Concretely, each test should create a well defined javadoc:org.springframework.context.ApplicationContext[] that represents a combination of those customizations.
+javadoc:org.springframework.boot.test.context.runner.ApplicationContextRunner[] provides a great way to achieve that.
-WARNING: `ApplicationContextRunner` doesn't work when running the tests in a native image.
+WARNING: javadoc:org.springframework.boot.test.context.runner.ApplicationContextRunner[] doesn't work when running the tests in a native image.
-`ApplicationContextRunner` is usually defined as a field of the test class to gather the base, common configuration.
+javadoc:org.springframework.boot.test.context.runner.ApplicationContextRunner[] is usually defined as a field of the test class to gather the base, common configuration.
The following example makes sure that `MyServiceAutoConfiguration` is always invoked:
include-code::MyServiceAutoConfigurationTests[tag=runner]
@@ -176,13 +176,13 @@ Invoking `run` provides a callback context that can be used with AssertJ.
include-code::MyServiceAutoConfigurationTests[tag=test-user-config]
-It is also possible to easily customize the `Environment`, as shown in the following example:
+It is also possible to easily customize the javadoc:org.springframework.core.env.Environment[], as shown in the following example:
include-code::MyServiceAutoConfigurationTests[tag=test-env]
-The runner can also be used to display the `ConditionEvaluationReport`.
+The runner can also be used to display the javadoc:org.springframework.boot.autoconfigure.condition.ConditionEvaluationReport[].
The report can be printed at `INFO` or `DEBUG` level.
-The following example shows how to use the `ConditionEvaluationReportLoggingListener` to print the report in auto-configuration tests.
+The following example shows how to use the javadoc:org.springframework.boot.autoconfigure.logging.ConditionEvaluationReportLoggingListener[] to print the report in auto-configuration tests.
include-code::MyConditionEvaluationReportingTests[]
@@ -191,7 +191,7 @@ include-code::MyConditionEvaluationReportingTests[]
[[features.developing-auto-configuration.testing.simulating-a-web-context]]
=== Simulating a Web Context
-If you need to test an auto-configuration that only operates in a servlet or reactive web application context, use the `WebApplicationContextRunner` or `ReactiveWebApplicationContextRunner` respectively.
+If you need to test an auto-configuration that only operates in a servlet or reactive web application context, use the javadoc:org.springframework.boot.test.context.runner.WebApplicationContextRunner[] or javadoc:org.springframework.boot.test.context.runner.ReactiveWebApplicationContextRunner[] respectively.
@@ -199,7 +199,7 @@ If you need to test an auto-configuration that only operates in a servlet or rea
=== Overriding the Classpath
It is also possible to test what happens when a particular class and/or package is not present at runtime.
-Spring Boot ships with a `FilteredClassLoader` that can easily be used by the runner.
+Spring Boot ships with a javadoc:org.springframework.boot.test.context.FilteredClassLoader[] that can easily be used by the runner.
In the following example, we assert that if `MyService` is not present, the auto-configuration is properly disabled:
include-code::../MyServiceAutoConfigurationTests[tag=test-classloader]
@@ -253,16 +253,16 @@ Make sure that configuration keys are documented by adding field Javadoc for eac
include-code::AcmeProperties[]
-NOTE: You should only use plain text with `@ConfigurationProperties` field Javadoc, since they are not processed before being added to the JSON.
+NOTE: You should only use plain text with javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] field Javadoc, since they are not processed before being added to the JSON.
-If you use `@ConfigurationProperties` with record class then record components' descriptions should be provided via class-level Javadoc tag `@param` (there are no explicit instance fields in record classes to put regular field-level Javadocs on).
+If you use javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] with record class then record components' descriptions should be provided via class-level Javadoc tag `@param` (there are no explicit instance fields in record classes to put regular field-level Javadocs on).
Here are some rules we follow internally to make sure descriptions are consistent:
* Do not start the description by "The" or "A".
* For `boolean` types, start the description with "Whether" or "Enable".
* For collection-based types, start the description with "Comma-separated list"
-* Use `java.time.Duration` rather than `long` and describe the default unit if it differs from milliseconds, such as "If a duration suffix is not specified, seconds will be used".
+* Use javadoc:java.time.Duration[] rather than `long` and describe the default unit if it differs from milliseconds, such as "If a duration suffix is not specified, seconds will be used".
* Do not provide the default value in the description unless it has to be determined at runtime.
Make sure to xref:specification:configuration-metadata/annotation-processor.adoc[trigger meta-data generation] so that IDE assistance is available for your keys as well.
@@ -275,7 +275,7 @@ Using your own starter in a compatible IDE is also a good idea to validate that
=== The "`autoconfigure`" Module
The `autoconfigure` module contains everything that is necessary to get started with the library.
-It may also contain configuration key definitions (such as `@ConfigurationProperties`) and any callback interface that can be used to further customize how the components are initialized.
+It may also contain configuration key definitions (such as javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation]) and any callback interface that can be used to further customize how the components are initialized.
TIP: You should mark the dependencies to the library as optional so that you can include the `autoconfigure` module in your projects more easily.
If you do it that way, the library is not provided and, by default, Spring Boot backs off.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/external-config.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/external-config.adoc
index a79c70276c..841a0db5fc 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/external-config.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/external-config.adoc
@@ -4,23 +4,23 @@
Spring Boot lets you externalize your configuration so that you can work with the same application code in different environments.
You can use a variety of external configuration sources including Java properties files, YAML files, environment variables, and command-line arguments.
-Property values can be injected directly into your beans by using the `@Value` annotation, accessed through Spring's `Environment` abstraction, or be xref:features/external-config.adoc#features.external-config.typesafe-configuration-properties[bound to structured objects] through `@ConfigurationProperties`.
+Property values can be injected directly into your beans by using the javadoc:org.springframework.beans.factory.annotation.Value[format=annotation] annotation, accessed through Spring's javadoc:org.springframework.core.env.Environment[] abstraction, or be xref:features/external-config.adoc#features.external-config.typesafe-configuration-properties[bound to structured objects] through javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation].
-Spring Boot uses a very particular `PropertySource` order that is designed to allow sensible overriding of values.
+Spring Boot uses a very particular javadoc:org.springframework.core.env.PropertySource[] order that is designed to allow sensible overriding of values.
Later property sources can override the values defined in earlier ones.
Sources are considered in the following order:
. Default properties (specified by setting javadoc:org.springframework.boot.SpringApplication#setDefaultProperties(java.util.Map)[]).
-. javadoc:{url-spring-framework-javadoc}/org.springframework.context.annotation.PropertySource[format=annotation] annotations on your `@Configuration` classes.
- Please note that such property sources are not added to the `Environment` until the application context is being refreshed.
+. javadoc:{url-spring-framework-javadoc}/org.springframework.context.annotation.PropertySource[format=annotation] annotations on your javadoc:org.springframework.context.annotation.Configuration[format=annotation] classes.
+ Please note that such property sources are not added to the javadoc:org.springframework.core.env.Environment[] until the application context is being refreshed.
This is too late to configure certain properties such as `+logging.*+` and `+spring.main.*+` which are read before refresh begins.
. Config data (such as `application.properties` files).
-. A `RandomValuePropertySource` that has properties only in `+random.*+`.
+. A javadoc:org.springframework.boot.env.RandomValuePropertySource[] that has properties only in `+random.*+`.
. OS environment variables.
. Java System properties (`System.getProperties()`).
. JNDI attributes from `java:comp/env`.
-. `ServletContext` init parameters.
-. `ServletConfig` init parameters.
+. javadoc:jakarta.servlet.ServletContext[] init parameters.
+. javadoc:jakarta.servlet.ServletConfig[] init parameters.
. Properties from `SPRING_APPLICATION_JSON` (inline JSON embedded in an environment variable or system property).
. Command line arguments.
. `properties` attribute on your tests.
@@ -44,7 +44,7 @@ See xref:features/external-config.adoc#features.external-config.typesafe-configu
NOTE: If your application runs in a servlet container or application server, then JNDI properties (in `java:comp/env`) or servlet context initialization parameters can be used instead of, or as well as, environment variables or system properties.
-To provide a concrete example, suppose you develop a `@Component` that uses a `name` property, as shown in the following example:
+To provide a concrete example, suppose you develop a javadoc:org.springframework.stereotype.Component[format=annotation] that uses a `name` property, as shown in the following example:
include-code::MyBean[]
@@ -61,10 +61,10 @@ See the xref:actuator/endpoints.adoc[Production ready features] section for deta
[[features.external-config.command-line-args]]
== Accessing Command Line Properties
-By default, `SpringApplication` converts any command line option arguments (that is, arguments starting with `--`, such as `--server.port=9000`) to a `property` and adds them to the Spring `Environment`.
+By default, javadoc:org.springframework.boot.SpringApplication[] converts any command line option arguments (that is, arguments starting with `--`, such as `--server.port=9000`) to a `property` and adds them to the Spring javadoc:org.springframework.core.env.Environment[].
As mentioned previously, command line properties always take precedence over file-based property sources.
-If you do not want command line properties to be added to the `Environment`, you can disable them by using `SpringApplication.setAddCommandLineProperties(false)`.
+If you do not want command line properties to be added to the javadoc:org.springframework.core.env.Environment[], you can disable them by using `SpringApplication.setAddCommandLineProperties(false)`.
@@ -74,7 +74,7 @@ If you do not want command line properties to be added to the `Environment`, you
Environment variables and system properties often have restrictions that mean some property names cannot be used.
To help with this, Spring Boot allows you to encode a block of properties into a single JSON structure.
-When your application starts, any `spring.application.json` or `SPRING_APPLICATION_JSON` properties will be parsed and added to the `Environment`.
+When your application starts, any `spring.application.json` or `SPRING_APPLICATION_JSON` properties will be parsed and added to the javadoc:org.springframework.core.env.Environment[].
For example, the `SPRING_APPLICATION_JSON` property can be supplied on the command line in a UN{asterisk}X shell as an environment variable:
@@ -83,7 +83,7 @@ For example, the `SPRING_APPLICATION_JSON` property can be supplied on the comma
$ SPRING_APPLICATION_JSON='{"my":{"name":"test"}}' java -jar myapp.jar
----
-In the preceding example, you end up with `my.name=test` in the Spring `Environment`.
+In the preceding example, you end up with `my.name=test` in the Spring javadoc:org.springframework.core.env.Environment[].
The same JSON can also be provided as a system property:
@@ -101,7 +101,7 @@ $ java -jar myapp.jar --spring.application.json='{"my":{"name":"test"}}'
If you are deploying to a classic Application Server, you could also use a JNDI variable named `java:comp/env/spring.application.json`.
-NOTE: Although `null` values from the JSON will be added to the resulting property source, the `PropertySourcesPropertyResolver` treats `null` properties as missing values.
+NOTE: Although `null` values from the JSON will be added to the resulting property source, the javadoc:org.springframework.core.env.PropertySourcesPropertyResolver[] treats `null` properties as missing values.
This means that the JSON cannot override properties from lower order property sources with a `null` value.
@@ -120,7 +120,7 @@ Spring Boot will automatically find and load `application.properties` and `appli
.. Immediate child directories of the `config/` subdirectory
The list is ordered by precedence (with values from lower items overriding earlier ones).
-Documents from the loaded files are added as `PropertySources` to the Spring `Environment`.
+Documents from the loaded files are added as javadoc:org.springframework.core.env.PropertySource[] instances to the Spring javadoc:org.springframework.core.env.Environment[].
If you do not like `application` as the configuration file name, you can switch to another file name by specifying a configprop:spring.config.name[] environment property.
For example, to look for `myproject.properties` and `myproject.yaml` files you can run your application as follows:
@@ -188,14 +188,14 @@ These default values can then be overridden at runtime with a different file loc
[[features.external-config.files.optional-prefix]]
=== Optional Locations
-By default, when a specified config data location does not exist, Spring Boot will throw a `ConfigDataLocationNotFoundException` and your application will not start.
+By default, when a specified config data location does not exist, Spring Boot will throw a javadoc:org.springframework.boot.context.config.ConfigDataLocationNotFoundException[] and your application will not start.
If you want to specify a location, but you do not mind if it does not always exist, you can use the `optional:` prefix.
You can use this prefix with the `spring.config.location` and `spring.config.additional-location` properties, as well as with xref:features/external-config.adoc#features.external-config.files.importing[`spring.config.import`] declarations.
For example, a `spring.config.import` value of `optional:file:./myconfig.properties` allows your application to start, even if the `myconfig.properties` file is missing.
-If you want to ignore all `ConfigDataLocationNotFoundException` errors and always continue to start your application, you can use the `spring.config.on-not-found` property.
+If you want to ignore all javadoc:org.springframework.boot.context.config.ConfigDataLocationNotFoundException[] errors and always continue to start your application, you can use the `spring.config.on-not-found` property.
Set the value to `ignore` using `SpringApplication.setDefaultProperties(...)` or with a system/environment variable.
@@ -263,7 +263,7 @@ When we have `classpath:/cfg/;classpath:/ext/` instead (with a `;` delimiter) we
. `/ext/application-live.properties`
====
-The `Environment` has a set of default profiles (by default, `[default]`) that are used if no active profiles are set.
+The javadoc:org.springframework.core.env.Environment[] has a set of default profiles (by default, `[default]`) that are used if no active profiles are set.
In other words, if no profiles are explicitly activated, then properties from `application-default` are considered.
NOTE: Properties files are only ever loaded once.
@@ -330,7 +330,7 @@ By default you can import Java Properties, YAML and xref:features/external-confi
Third-party jars can offer support for additional technologies (there is no requirement for files to be local).
For example, you can imagine config data being from external stores such as Consul, Apache ZooKeeper or Netflix Archaius.
-If you want to support your own locations, see the `ConfigDataLocationResolver` and `ConfigDataLoader` classes in the `org.springframework.boot.context.config` package.
+If you want to support your own locations, see the javadoc:org.springframework.boot.context.config.ConfigDataLocationResolver[] and javadoc:org.springframework.boot.context.config.ConfigDataLoader[] classes in the `org.springframework.boot.context.config` package.
====
@@ -393,15 +393,15 @@ spring:
import: "optional:configtree:/etc/config/"
----
-You can then access or inject `myapp.username` and `myapp.password` properties from the `Environment` in the usual way.
+You can then access or inject `myapp.username` and `myapp.password` properties from the javadoc:org.springframework.core.env.Environment[] in the usual way.
TIP: The names of the folders and files under the config tree form the property name.
In the above example, to access the properties as `username` and `password`, you can set `spring.config.import` to `optional:configtree:/etc/config/myapp`.
NOTE: Filenames with dot notation are also correctly mapped.
-For example, in the above example, a file named `myapp.username` in `/etc/config` would result in a `myapp.username` property in the `Environment`.
+For example, in the above example, a file named `myapp.username` in `/etc/config` would result in a `myapp.username` property in the javadoc:org.springframework.core.env.Environment[].
-TIP: Configuration tree values can be bound to both string `String` and `byte[]` types depending on the contents expected.
+TIP: Configuration tree values can be bound to both string javadoc:java.lang.String[] and `byte[]` types depending on the contents expected.
If you have multiple config trees to import from the same parent folder you can use a wildcard shortcut.
Any `configtree:` location that ends with `/*/` will import all immediate children as config trees.
@@ -454,7 +454,7 @@ spring:
[[features.external-config.files.property-placeholders]]
=== Property Placeholders
-The values in `application.properties` and `application.yaml` are filtered through the existing `Environment` when they are used, so you can refer back to previously defined values (for example, from System properties or environment variables).
+The values in `application.properties` and `application.yaml` are filtered through the existing javadoc:org.springframework.core.env.Environment[] when they are used, so you can refer back to previously defined values (for example, from System properties or environment variables).
The standard `$\{name}` property-placeholder syntax can be used anywhere within a value.
Property placeholders can also specify a default value using a `:` to separate the default value from the property name, for example `${name:default}`.
@@ -472,7 +472,7 @@ Assuming that the `username` property has not been set elsewhere, `app.descripti
[NOTE]
====
You should always refer to property names in the placeholder using their canonical form (kebab-case using only lowercase letters).
-This will allow Spring Boot to use the same logic as it does when xref:features/external-config.adoc#features.external-config.typesafe-configuration-properties.relaxed-binding[relaxed binding] `@ConfigurationProperties`.
+This will allow Spring Boot to use the same logic as it does when xref:features/external-config.adoc#features.external-config.typesafe-configuration-properties.relaxed-binding[relaxed binding] javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation].
For example, `${demo.item-price}` will pick up `demo.item-price` and `demo.itemPrice` forms from the `application.properties` file, as well as `DEMO_ITEMPRICE` from the system environment.
If you used `${demo.itemPrice}` instead, `demo.item-price` and `DEMO_ITEMPRICE` would not be considered.
@@ -525,7 +525,7 @@ The lines immediately before and after the separator must not be same comment pr
TIP: Multi-document property files are often used in conjunction with activation properties such as `spring.config.activate.on-profile`.
See the xref:features/external-config.adoc#features.external-config.files.activation-properties[next section] for details.
-WARNING: Multi-document property files cannot be loaded by using the `@PropertySource` or `@TestPropertySource` annotations.
+WARNING: Multi-document property files cannot be loaded by using the javadoc:org.springframework.context.annotation.PropertySource[format=annotation] or javadoc:org.springframework.test.context.TestPropertySource[format=annotation] annotations.
@@ -548,7 +548,7 @@ The following activation properties are available:
| A profile expression that must match for the document to be active.
| `on-cloud-platform`
-| The `CloudPlatform` that must be detected for the document to be active.
+| The javadoc:org.springframework.boot.cloud.CloudPlatform[] that must be detected for the document to be active.
|===
For example, the following specifies that the second document is only active when running on Kubernetes, and only when either the "`prod`" or "`staging`" profiles are active:
@@ -571,8 +571,8 @@ myotherprop: "sometimes-set"
[[features.external-config.encrypting]]
== Encrypting Properties
-Spring Boot does not provide any built-in support for encrypting property values, however, it does provide the hook points necessary to modify values contained in the Spring `Environment`.
-The `EnvironmentPostProcessor` interface allows you to manipulate the `Environment` before the application starts.
+Spring Boot does not provide any built-in support for encrypting property values, however, it does provide the hook points necessary to modify values contained in the Spring javadoc:org.springframework.core.env.Environment[].
+The javadoc:org.springframework.boot.env.EnvironmentPostProcessor[] interface allows you to manipulate the javadoc:org.springframework.core.env.Environment[] before the application starts.
See xref:how-to:application.adoc#howto.application.customize-the-environment-or-application-context[] for details.
If you need a secure way to store credentials and passwords, the https://cloud.spring.io/spring-cloud-vault/[Spring Cloud Vault] project provides support for storing externalized configuration in https://www.vaultproject.io/[HashiCorp Vault].
@@ -583,7 +583,7 @@ If you need a secure way to store credentials and passwords, the https://cloud.s
== Working With YAML
https://yaml.org[YAML] is a superset of JSON and, as such, is a convenient format for specifying hierarchical configuration data.
-The `SpringApplication` class automatically supports YAML as an alternative to properties whenever you have the https://github.com/snakeyaml/snakeyaml[SnakeYAML] library on your classpath.
+The javadoc:org.springframework.boot.SpringApplication[] class automatically supports YAML as an alternative to properties whenever you have the https://github.com/snakeyaml/snakeyaml[SnakeYAML] library on your classpath.
NOTE: If you use starters, SnakeYAML is automatically provided by `spring-boot-starter`.
@@ -592,7 +592,7 @@ NOTE: If you use starters, SnakeYAML is automatically provided by `spring-boot-s
[[features.external-config.yaml.mapping-to-properties]]
=== Mapping YAML to Properties
-YAML documents need to be converted from their hierarchical format to a flat structure that can be used with the Spring `Environment`.
+YAML documents need to be converted from their hierarchical format to a flat structure that can be used with the Spring javadoc:org.springframework.core.env.Environment[].
For example, consider the following YAML document:
[source,yaml]
@@ -606,7 +606,7 @@ environments:
name: "My Cool App"
----
-In order to access these properties from the `Environment`, they would be flattened as follows:
+In order to access these properties from the javadoc:org.springframework.core.env.Environment[], they would be flattened as follows:
[source,properties]
----
@@ -636,10 +636,10 @@ my.servers[0]=dev.example.com
my.servers[1]=another.example.com
----
-TIP: Properties that use the `[index]` notation can be bound to Java `List` or `Set` objects using Spring Boot's `Binder` class.
+TIP: Properties that use the `[index]` notation can be bound to Java javadoc:java.util.List[] or javadoc:java.util.Set[] objects using Spring Boot's javadoc:org.springframework.boot.context.properties.bind.Binder[] class.
For more details see the xref:features/external-config.adoc#features.external-config.typesafe-configuration-properties[] section below.
-WARNING: YAML files cannot be loaded by using the `@PropertySource` or `@TestPropertySource` annotations.
+WARNING: YAML files cannot be loaded by using the javadoc:org.springframework.context.annotation.PropertySource[format=annotation] or javadoc:org.springframework.test.context.TestPropertySource[format=annotation] annotations.
So, in the case that you need to load values that way, you need to use a properties file.
@@ -648,16 +648,16 @@ So, in the case that you need to load values that way, you need to use a propert
=== Directly Loading YAML
Spring Framework provides two convenient classes that can be used to load YAML documents.
-The `YamlPropertiesFactoryBean` loads YAML as `Properties` and the `YamlMapFactoryBean` loads YAML as a `Map`.
+The javadoc:org.springframework.beans.factory.config.YamlPropertiesFactoryBean[] loads YAML as javadoc:java.util.Properties[] and the javadoc:org.springframework.beans.factory.config.YamlMapFactoryBean[] loads YAML as a javadoc:java.util.Map[].
-You can also use the `YamlPropertySourceLoader` class if you want to load YAML as a Spring `PropertySource`.
+You can also use the javadoc:org.springframework.boot.env.YamlPropertySourceLoader[] class if you want to load YAML as a Spring javadoc:org.springframework.core.env.PropertySource[].
[[features.external-config.random-values]]
== Configuring Random Values
-The `RandomValuePropertySource` is useful for injecting random values (for example, into secrets or test cases).
+The javadoc:org.springframework.boot.env.RandomValuePropertySource[] is useful for injecting random values (for example, into secrets or test cases).
It can produce integers, longs, uuids, or strings, as shown in the following example:
[configprops%novalidate,yaml]
@@ -681,7 +681,7 @@ If `max` is provided, then `value` is the minimum value and `max` is the maximum
Spring Boot supports setting a prefix for environment properties.
This is useful if the system environment is shared by multiple Spring Boot applications with different configuration requirements.
-The prefix for system environment properties can be set directly on `SpringApplication`.
+The prefix for system environment properties can be set directly on javadoc:org.springframework.boot.SpringApplication[].
For example, if you set the prefix to `input`, a property such as `remote.timeout` will also be resolved as `input.remote.timeout` in the system environment.
@@ -693,7 +693,7 @@ For example, if you set the prefix to `input`, a property such as `remote.timeou
Using the `@Value("$\{property}")` annotation to inject configuration properties can sometimes be cumbersome, especially if you are working with multiple properties or your data is hierarchical in nature.
Spring Boot provides an alternative method of working with properties that lets strongly typed beans govern and validate the configuration of your application.
-TIP: See also the xref:features/external-config.adoc#features.external-config.typesafe-configuration-properties.vs-value-annotation[differences between `@Value` and type-safe configuration properties].
+TIP: See also the xref:features/external-config.adoc#features.external-config.typesafe-configuration-properties.vs-value-annotation[differences between javadoc:org.springframework.beans.factory.annotation.Value[format=annotation] and type-safe configuration properties].
@@ -707,13 +707,13 @@ include-code::MyProperties[]
The preceding POJO defines the following properties:
* `my.service.enabled`, with a value of `false` by default.
-* `my.service.remote-address`, with a type that can be coerced from `String`.
+* `my.service.remote-address`, with a type that can be coerced from javadoc:java.lang.String[].
* `my.service.security.username`, with a nested "security" object whose name is determined by the name of the property.
- In particular, the type is not used at all there and could have been `SecurityProperties`.
+ In particular, the type is not used at all there and could have been javadoc:org.springframework.boot.autoconfigure.security.SecurityProperties[].
* `my.service.security.password`.
-* `my.service.security.roles`, with a collection of `String` that defaults to `USER`.
+* `my.service.security.roles`, with a collection of javadoc:java.lang.String[] that defaults to `USER`.
-NOTE: The properties that map to `@ConfigurationProperties` classes available in Spring Boot, which are configured through properties files, YAML files, environment variables, and other mechanisms, are public API but the accessors (getters/setters) of the class itself are not meant to be used directly.
+NOTE: The properties that map to javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] classes available in Spring Boot, which are configured through properties files, YAML files, environment variables, and other mechanisms, are public API but the accessors (getters/setters) of the class itself are not meant to be used directly.
[NOTE]
====
@@ -745,50 +745,50 @@ include-code::MyProperties[]
In this setup, the presence of a single parameterized constructor implies that constructor binding should be used.
This means that the binder will find a constructor with the parameters that you wish to have bound.
-If your class has multiple constructors, the `@ConstructorBinding` annotation can be used to specify which constructor to use for constructor binding.
-To opt out of constructor binding for a class with a single parameterized constructor, the constructor must be annotated with `@Autowired` or made `private`.
+If your class has multiple constructors, the javadoc:org.springframework.boot.context.properties.bind.ConstructorBinding[format=annotation] annotation can be used to specify which constructor to use for constructor binding.
+To opt out of constructor binding for a class with a single parameterized constructor, the constructor must be annotated with javadoc:org.springframework.beans.factory.annotation.Autowired[format=annotation] or made `private`.
Constructor binding can be used with records.
-Unless your record has multiple constructors, there is no need to use `@ConstructorBinding`.
+Unless your record has multiple constructors, there is no need to use javadoc:org.springframework.boot.context.properties.bind.ConstructorBinding[format=annotation].
Nested members of a constructor bound class (such as `Security` in the example above) will also be bound through their constructor.
-Default values can be specified using `@DefaultValue` on constructor parameters and record components.
-The conversion service will be applied to coerce the annotation's `String` value to the target type of a missing property.
+Default values can be specified using javadoc:org.springframework.boot.context.properties.bind.DefaultValue[format=annotation] on constructor parameters and record components.
+The conversion service will be applied to coerce the annotation's javadoc:java.lang.String[] value to the target type of a missing property.
Referring to the previous example, if no properties are bound to `Security`, the `MyProperties` instance will contain a `null` value for `security`.
-To make it contain a non-null instance of `Security` even when no properties are bound to it (when using Kotlin, this will require the `username` and `password` parameters of `Security` to be declared as nullable as they do not have default values), use an empty `@DefaultValue` annotation:
+To make it contain a non-null instance of `Security` even when no properties are bound to it (when using Kotlin, this will require the `username` and `password` parameters of `Security` to be declared as nullable as they do not have default values), use an empty javadoc:org.springframework.boot.context.properties.bind.DefaultValue[format=annotation] annotation:
include-code::nonnull/MyProperties[tag=*]
-NOTE: To use constructor binding the class must be enabled using `@EnableConfigurationProperties` or configuration property scanning.
-You cannot use constructor binding with beans that are created by the regular Spring mechanisms (for example `@Component` beans, beans created by using `@Bean` methods or beans loaded by using `@Import`)
+NOTE: To use constructor binding the class must be enabled using javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] or configuration property scanning.
+You cannot use constructor binding with beans that are created by the regular Spring mechanisms (for example javadoc:org.springframework.stereotype.Component[format=annotation] beans, beans created by using javadoc:org.springframework.context.annotation.Bean[format=annotation] methods or beans loaded by using javadoc:org.springframework.context.annotation.Import[format=annotation])
NOTE: To use constructor binding the class must be compiled with `-parameters`.
This will happen automatically if you use Spring Boot's Gradle plugin or if you use Maven and `spring-boot-starter-parent`.
-NOTE: The use of `java.util.Optional` with `@ConfigurationProperties` is not recommended as it is primarily intended for use as a return type.
+NOTE: The use of javadoc:java.util.Optional[] with javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] is not recommended as it is primarily intended for use as a return type.
As such, it is not well-suited to configuration property injection.
-For consistency with properties of other types, if you do declare an `Optional` property and it has no value, `null` rather than an empty `Optional` will be bound.
+For consistency with properties of other types, if you do declare an javadoc:java.util.Optional[] property and it has no value, `null` rather than an empty javadoc:java.util.Optional[] will be bound.
-TIP: To use a reserved keyword in the name of a property, such as `my.service.import`, use the `@Name` annotation on the constructor parameter.
+TIP: To use a reserved keyword in the name of a property, such as `my.service.import`, use the javadoc:org.springframework.boot.context.properties.bind.Name[format=annotation] annotation on the constructor parameter.
[[features.external-config.typesafe-configuration-properties.enabling-annotated-types]]
=== Enabling @ConfigurationProperties-annotated Types
-Spring Boot provides infrastructure to bind `@ConfigurationProperties` types and register them as beans.
+Spring Boot provides infrastructure to bind javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] types and register them as beans.
You can either enable configuration properties on a class-by-class basis or enable configuration property scanning that works in a similar manner to component scanning.
-Sometimes, classes annotated with `@ConfigurationProperties` might not be suitable for scanning, for example, if you're developing your own auto-configuration or you want to enable them conditionally.
-In these cases, specify the list of types to process using the `@EnableConfigurationProperties` annotation.
-This can be done on any `@Configuration` class, as shown in the following example:
+Sometimes, classes annotated with javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] might not be suitable for scanning, for example, if you're developing your own auto-configuration or you want to enable them conditionally.
+In these cases, specify the list of types to process using the javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] annotation.
+This can be done on any javadoc:org.springframework.context.annotation.Configuration[format=annotation] class, as shown in the following example:
include-code::MyConfiguration[]
include-code::SomeProperties[]
-To use configuration property scanning, add the `@ConfigurationPropertiesScan` annotation to your application.
-Typically, it is added to the main application class that is annotated with `@SpringBootApplication` but it can be added to any `@Configuration` class.
+To use configuration property scanning, add the javadoc:org.springframework.boot.context.properties.ConfigurationPropertiesScan[format=annotation] annotation to your application.
+Typically, it is added to the main application class that is annotated with javadoc:org.springframework.boot.autoconfigure.SpringBootApplication[format=annotation] but it can be added to any javadoc:org.springframework.context.annotation.Configuration[format=annotation] class.
By default, scanning will occur from the package of the class that declares the annotation.
If you want to define specific packages to scan, you can do so as shown in the following example:
@@ -796,22 +796,22 @@ include-code::MyApplication[]
[NOTE]
====
-When the `@ConfigurationProperties` bean is registered using configuration property scanning or through `@EnableConfigurationProperties`, the bean has a conventional name: `-`, where `` is the environment key prefix specified in the `@ConfigurationProperties` annotation and `` is the fully qualified name of the bean.
+When the javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] bean is registered using configuration property scanning or through javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation], the bean has a conventional name: `-`, where `` is the environment key prefix specified in the javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] annotation and `` is the fully qualified name of the bean.
If the annotation does not provide any prefix, only the fully qualified name of the bean is used.
Assuming that it is in the `com.example.app` package, the bean name of the `SomeProperties` example above is `some.properties-com.example.app.SomeProperties`.
====
-We recommend that `@ConfigurationProperties` only deal with the environment and, in particular, does not inject other beans from the context.
-For corner cases, setter injection can be used or any of the `*Aware` interfaces provided by the framework (such as `EnvironmentAware` if you need access to the `Environment`).
-If you still want to inject other beans using the constructor, the configuration properties bean must be annotated with `@Component` and use JavaBean-based property binding.
+We recommend that javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] only deal with the environment and, in particular, does not inject other beans from the context.
+For corner cases, setter injection can be used or any of the `*Aware` interfaces provided by the framework (such as javadoc:org.springframework.context.EnvironmentAware[] if you need access to the javadoc:org.springframework.core.env.Environment[]).
+If you still want to inject other beans using the constructor, the configuration properties bean must be annotated with javadoc:org.springframework.stereotype.Component[format=annotation] and use JavaBean-based property binding.
[[features.external-config.typesafe-configuration-properties.using-annotated-types]]
=== Using @ConfigurationProperties-annotated Types
-This style of configuration works particularly well with the `SpringApplication` external YAML configuration, as shown in the following example:
+This style of configuration works particularly well with the javadoc:org.springframework.boot.SpringApplication[] external YAML configuration, as shown in the following example:
[source,yaml]
----
@@ -825,11 +825,11 @@ my:
- "ADMIN"
----
-To work with `@ConfigurationProperties` beans, you can inject them in the same way as any other bean, as shown in the following example:
+To work with javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans, you can inject them in the same way as any other bean, as shown in the following example:
include-code::MyService[]
-TIP: Using `@ConfigurationProperties` also lets you generate metadata files that can be used by IDEs to offer auto-completion for your own keys.
+TIP: Using javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] also lets you generate metadata files that can be used by IDEs to offer auto-completion for your own keys.
See the xref:specification:configuration-metadata/index.adoc[appendix] for details.
@@ -837,10 +837,10 @@ See the xref:specification:configuration-metadata/index.adoc[appendix] for detai
[[features.external-config.typesafe-configuration-properties.third-party-configuration]]
=== Third-party Configuration
-As well as using `@ConfigurationProperties` to annotate a class, you can also use it on public `@Bean` methods.
+As well as using javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] to annotate a class, you can also use it on public javadoc:org.springframework.context.annotation.Bean[format=annotation] methods.
Doing so can be particularly useful when you want to bind properties to third-party components that are outside of your control.
-To configure a bean from the `Environment` properties, add `@ConfigurationProperties` to its bean registration, as shown in the following example:
+To configure a bean from the javadoc:org.springframework.core.env.Environment[] properties, add javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] to its bean registration, as shown in the following example:
include-code::ThirdPartyConfiguration[]
@@ -851,10 +851,10 @@ Any JavaBean property defined with the `another` prefix is mapped onto that `Ano
[[features.external-config.typesafe-configuration-properties.relaxed-binding]]
=== Relaxed Binding
-Spring Boot uses some relaxed rules for binding `Environment` properties to `@ConfigurationProperties` beans, so there does not need to be an exact match between the `Environment` property name and the bean property name.
+Spring Boot uses some relaxed rules for binding javadoc:org.springframework.core.env.Environment[] properties to javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans, so there does not need to be an exact match between the javadoc:org.springframework.core.env.Environment[] property name and the bean property name.
Common examples where this is useful include dash-separated environment properties (for example, `context-path` binds to `contextPath`), and capitalized environment properties (for example, `PORT` binds to `port`).
-As an example, consider the following `@ConfigurationProperties` class:
+As an example, consider the following javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] class:
include-code::MyPersonProperties[]
@@ -909,7 +909,7 @@ TIP: We recommend that, when possible, properties are stored in lower-case kebab
[[features.external-config.typesafe-configuration-properties.relaxed-binding.maps]]
==== Binding Maps
-When binding to `Map` properties you may need to use a special bracket notation so that the original `key` value is preserved.
+When binding to javadoc:java.util.Map[] properties you may need to use a special bracket notation so that the original `key` value is preserved.
If the key is not surrounded by `[]`, any characters that are not alpha-numeric, `-` or `.` are removed.
For example, consider binding the following properties to a `Map`:
@@ -925,11 +925,11 @@ my:
NOTE: For YAML files, the brackets need to be surrounded by quotes for the keys to be parsed properly.
-The properties above will bind to a `Map` with `/key1`, `/key2` and `key3` as the keys in the map.
+The properties above will bind to a javadoc:java.util.Map[] with `/key1`, `/key2` and `key3` as the keys in the map.
The slash has been removed from `key3` because it was not surrounded by square brackets.
When binding to scalar values, keys with `.` in them do not need to be surrounded by `[]`.
-Scalar values include enums and all types in the `java.lang` package except for `Object`.
+Scalar values include enums and all types in the `java.lang` package except for javadoc:java.lang.Object[].
Binding `a.b=c` to `Map` will preserve the `.` in the key and return a Map with the entry `{"a.b"="c"}`.
For any other types you need to use the bracket notation if your `key` contains a `.`.
For example, binding `a.b=c` to `Map` will return a Map with the entry `{"a"={"b"="c"}}` whereas `[a.b]=c` will return a Map with the entry `{"a.b"="c"}`.
@@ -954,7 +954,8 @@ To convert a property name in the canonical-form to an environment variable name
For example, the configuration property `spring.main.log-startup-info` would be an environment variable named `SPRING_MAIN_LOGSTARTUPINFO`.
Environment variables can also be used when binding to object lists.
-To bind to a `List`, the element number should be surrounded with underscores in the variable name.
+To bind to a javadoc:java.util.List[], the element number should be surrounded with underscores in the variable name.
+
For example, the configuration property `my.service[0].other` would use an environment variable named `MY_SERVICE_0_OTHER`.
Support for binding from environment variables is applied to the `systemEnvironment` property source and to any additional property source whose name ends with `-systemEnvironment`.
@@ -965,16 +966,16 @@ Support for binding from environment variables is applied to the `systemEnvironm
==== Binding Maps From Environment Variables
When Spring Boot binds an environment variable to a property class, it lowercases the environment variable name before binding.
-Most of the time this detail isn't important, except when binding to `Map` properties.
+Most of the time this detail isn't important, except when binding to javadoc:java.util.Map[] properties.
-The keys in the `Map` are always in lowercase, as seen in the following example:
+The keys in the javadoc:java.util.Map[] are always in lowercase, as seen in the following example:
include-code::MyMapsProperties[]
-When setting `MY_PROPS_VALUES_KEY=value`, the `values` `Map` contains a `{"key"="value"}` entry.
+When setting `MY_PROPS_VALUES_KEY=value`, the `values` javadoc:java.util.Map[] contains a `{"key"="value"}` entry.
Only the environment variable *name* is lower-cased, not the value.
-When setting `MY_PROPS_VALUES_KEY=VALUE`, the `values` `Map` contains a `{"key"="VALUE"}` entry.
+When setting `MY_PROPS_VALUES_KEY=VALUE`, the `values` javadoc:java.util.Map[] contains a `{"key"="VALUE"}` entry.
@@ -982,7 +983,7 @@ When setting `MY_PROPS_VALUES_KEY=VALUE`, the `values` `Map` contains a `{"key"=
==== Caching
Relaxed binding uses a cache to improve performance. By default, this caching is only applied to immutable property sources.
-To customize this behavior, for example to enable caching for mutable property sources, use `ConfigurationPropertyCaching`.
+To customize this behavior, for example to enable caching for mutable property sources, use javadoc:org.springframework.boot.context.properties.source.ConfigurationPropertyCaching[].
@@ -1018,7 +1019,7 @@ If the `dev` profile is not active, `MyProperties.list` contains one `MyPojo` en
If the `dev` profile is enabled, however, the `list` _still_ contains only one entry (with a name of `my another name` and a description of `null`).
This configuration _does not_ add a second `MyPojo` instance to the list, and it does not merge the items.
-When a `List` is specified in multiple profiles, the one with the highest priority (and only that one) is used.
+When a javadoc:java.util.List[] is specified in multiple profiles, the one with the highest priority (and only that one) is used.
Consider the following example:
[configprops%novalidate,yaml]
@@ -1042,7 +1043,7 @@ my:
In the preceding example, if the `dev` profile is active, `MyProperties.list` contains _one_ `MyPojo` entry (with a name of `my another name` and a description of `null`).
For YAML, both comma-separated lists and YAML lists can be used for completely overriding the contents of the list.
-For `Map` properties, you can bind with property values drawn from multiple sources.
+For javadoc:java.util.Map[] properties, you can bind with property values drawn from multiple sources.
However, for the same property in multiple sources, the one with the highest priority is used.
The following example exposes a `Map` from `MyProperties`:
@@ -1081,12 +1082,12 @@ NOTE: The preceding merging rules apply to properties from all property sources,
[[features.external-config.typesafe-configuration-properties.conversion]]
=== Properties Conversion
-Spring Boot attempts to coerce the external application properties to the right type when it binds to the `@ConfigurationProperties` beans.
-If you need custom type conversion, you can provide a `ConversionService` bean (with a bean named `conversionService`) or custom property editors (through a `CustomEditorConfigurer` bean) or custom converters (with bean definitions annotated as `@ConfigurationPropertiesBinding`).
+Spring Boot attempts to coerce the external application properties to the right type when it binds to the javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans.
+If you need custom type conversion, you can provide a javadoc:org.springframework.core.convert.ConversionService[] bean (with a bean named `conversionService`) or custom property editors (through a javadoc:org.springframework.beans.factory.config.CustomEditorConfigurer[] bean) or custom converters (with bean definitions annotated as javadoc:org.springframework.boot.context.properties.ConfigurationPropertiesBinding[format=annotation]).
-NOTE: As this bean is requested very early during the application lifecycle, make sure to limit the dependencies that your `ConversionService` is using.
+NOTE: As this bean is requested very early during the application lifecycle, make sure to limit the dependencies that your javadoc:org.springframework.core.convert.ConversionService[] is using.
Typically, any dependency that you require may not be fully initialized at creation time.
-You may want to rename your custom `ConversionService` if it is not required for configuration keys coercion and only rely on custom converters qualified with `@ConfigurationPropertiesBinding`.
+You may want to rename your custom javadoc:org.springframework.core.convert.ConversionService[] if it is not required for configuration keys coercion and only rely on custom converters qualified with javadoc:org.springframework.boot.context.properties.ConfigurationPropertiesBinding[format=annotation].
@@ -1094,10 +1095,10 @@ You may want to rename your custom `ConversionService` if it is not required for
==== Converting Durations
Spring Boot has dedicated support for expressing durations.
-If you expose a `java.time.Duration` property, the following formats in application properties are available:
+If you expose a javadoc:java.time.Duration[] property, the following formats in application properties are available:
-* A regular `long` representation (using milliseconds as the default unit unless a `@DurationUnit` has been specified)
-* The standard ISO-8601 format {apiref-openjdk}/java.base/java/time/Duration.html#parse(java.lang.CharSequence)[used by `java.time.Duration`]
+* A regular `long` representation (using milliseconds as the default unit unless a javadoc:org.springframework.boot.convert.DurationUnit[format=annotation] has been specified)
+* The standard ISO-8601 format {apiref-openjdk}/java.base/java/time/Duration.html#parse(java.lang.CharSequence)[used by javadoc:java.time.Duration[]]
* A more readable format where the value and the unit are coupled (`10s` means 10 seconds)
Consider the following example:
@@ -1118,14 +1119,14 @@ These are:
* `h` for hours
* `d` for days
-The default unit is milliseconds and can be overridden using `@DurationUnit` as illustrated in the sample above.
+The default unit is milliseconds and can be overridden using javadoc:org.springframework.boot.convert.DurationUnit[format=annotation] as illustrated in the sample above.
If you prefer to use constructor binding, the same properties can be exposed, as shown in the following example:
include-code::constructorbinding/MyProperties[]
-TIP: If you are upgrading a `Long` property, make sure to define the unit (using `@DurationUnit`) if it is not milliseconds.
+TIP: If you are upgrading a javadoc:java.lang.Long[] property, make sure to define the unit (using javadoc:org.springframework.boot.convert.DurationUnit[format=annotation]) if it is not milliseconds.
Doing so gives a transparent upgrade path while supporting a much richer format.
@@ -1133,11 +1134,11 @@ Doing so gives a transparent upgrade path while supporting a much richer format.
[[features.external-config.typesafe-configuration-properties.conversion.periods]]
==== Converting Periods
-In addition to durations, Spring Boot can also work with `java.time.Period` type.
+In addition to durations, Spring Boot can also work with javadoc:java.time.Period[] type.
The following formats can be used in application properties:
-* An regular `int` representation (using days as the default unit unless a `@PeriodUnit` has been specified)
-* The standard ISO-8601 format {apiref-openjdk}/java.base/java/time/Period.html#parse(java.lang.CharSequence)[used by `java.time.Period`]
+* An regular `int` representation (using days as the default unit unless a javadoc:org.springframework.boot.convert.PeriodUnit[format=annotation] has been specified)
+* The standard ISO-8601 format {apiref-openjdk}/java.base/java/time/Period.html#parse(java.lang.CharSequence)[used by javadoc:java.time.Period[]]
* A simpler format where the value and the unit pairs are coupled (`1y3d` means 1 year and 3 days)
The following units are supported with the simple format:
@@ -1147,17 +1148,17 @@ The following units are supported with the simple format:
* `w` for weeks
* `d` for days
-NOTE: The `java.time.Period` type never actually stores the number of weeks, it is a shortcut that means "`7 days`".
+NOTE: The javadoc:java.time.Period[] type never actually stores the number of weeks, it is a shortcut that means "`7 days`".
[[features.external-config.typesafe-configuration-properties.conversion.data-sizes]]
==== Converting Data Sizes
-Spring Framework has a `DataSize` value type that expresses a size in bytes.
-If you expose a `DataSize` property, the following formats in application properties are available:
+Spring Framework has a javadoc:org.springframework.util.unit.DataSize[] value type that expresses a size in bytes.
+If you expose a javadoc:org.springframework.util.unit.DataSize[] property, the following formats in application properties are available:
-* A regular `long` representation (using bytes as the default unit unless a `@DataSizeUnit` has been specified)
+* A regular `long` representation (using bytes as the default unit unless a javadoc:org.springframework.boot.convert.DataSizeUnit[format=annotation] has been specified)
* A more readable format where the value and the unit are coupled (`10MB` means 10 megabytes)
Consider the following example:
@@ -1176,13 +1177,13 @@ These are:
* `GB` for gigabytes
* `TB` for terabytes
-The default unit is bytes and can be overridden using `@DataSizeUnit` as illustrated in the sample above.
+The default unit is bytes and can be overridden using javadoc:org.springframework.boot.convert.DataSizeUnit[format=annotation] as illustrated in the sample above.
If you prefer to use constructor binding, the same properties can be exposed, as shown in the following example:
include-code::constructorbinding/MyProperties[]
-TIP: If you are upgrading a `Long` property, make sure to define the unit (using `@DataSizeUnit`) if it is not bytes.
+TIP: If you are upgrading a javadoc:java.lang.Long[] property, make sure to define the unit (using javadoc:org.springframework.boot.convert.DataSizeUnit[format=annotation]) if it is not bytes.
Doing so gives a transparent upgrade path while supporting a much richer format.
@@ -1190,25 +1191,25 @@ Doing so gives a transparent upgrade path while supporting a much richer format.
[[features.external-config.typesafe-configuration-properties.validation]]
=== @ConfigurationProperties Validation
-Spring Boot attempts to validate `@ConfigurationProperties` classes whenever they are annotated with Spring's `@Validated` annotation.
+Spring Boot attempts to validate javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] classes whenever they are annotated with Spring's javadoc:org.springframework.validation.annotation.Validated[format=annotation] annotation.
You can use JSR-303 `jakarta.validation` constraint annotations directly on your configuration class.
To do so, ensure that a compliant JSR-303 implementation is on your classpath and then add constraint annotations to your fields, as shown in the following example:
include-code::MyProperties[]
-TIP: You can also trigger validation by annotating the `@Bean` method that creates the configuration properties with `@Validated`.
+TIP: You can also trigger validation by annotating the javadoc:org.springframework.context.annotation.Bean[format=annotation] method that creates the configuration properties with javadoc:org.springframework.validation.annotation.Validated[format=annotation].
-To ensure that validation is always triggered for nested properties, even when no properties are found, the associated field must be annotated with `@Valid`.
+To ensure that validation is always triggered for nested properties, even when no properties are found, the associated field must be annotated with javadoc:jakarta.validation.Valid[format=annotation].
The following example builds on the preceding `MyProperties` example:
include-code::nested/MyProperties[]
-You can also add a custom Spring `Validator` by creating a bean definition called `configurationPropertiesValidator`.
-The `@Bean` method should be declared `static`.
-The configuration properties validator is created very early in the application's lifecycle, and declaring the `@Bean` method as static lets the bean be created without having to instantiate the `@Configuration` class.
+You can also add a custom Spring javadoc:org.springframework.validation.Validator[] by creating a bean definition called `configurationPropertiesValidator`.
+The javadoc:org.springframework.context.annotation.Bean[format=annotation] method should be declared `static`.
+The configuration properties validator is created very early in the application's lifecycle, and declaring the javadoc:org.springframework.context.annotation.Bean[format=annotation] method as static lets the bean be created without having to instantiate the javadoc:org.springframework.context.annotation.Configuration[format=annotation] class.
Doing so avoids any problems that may be caused by early instantiation.
-TIP: The `spring-boot-actuator` module includes an endpoint that exposes all `@ConfigurationProperties` beans.
+TIP: The `spring-boot-actuator` module includes an endpoint that exposes all javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans.
Point your web browser to `/actuator/configprops` or use the equivalent JMX endpoint.
See the xref:actuator/endpoints.adoc[Production ready features] section for details.
@@ -1217,8 +1218,8 @@ See the xref:actuator/endpoints.adoc[Production ready features] section for deta
[[features.external-config.typesafe-configuration-properties.vs-value-annotation]]
=== @ConfigurationProperties vs. @Value
-The `@Value` annotation is a core container feature, and it does not provide the same features as type-safe configuration properties.
-The following table summarizes the features that are supported by `@ConfigurationProperties` and `@Value`:
+The javadoc:org.springframework.beans.factory.annotation.Value[format=annotation] annotation is a core container feature, and it does not provide the same features as type-safe configuration properties.
+The following table summarizes the features that are supported by javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] and javadoc:org.springframework.beans.factory.annotation.Value[format=annotation]:
[cols="4,2,2"]
|===
@@ -1240,16 +1241,16 @@ The following table summarizes the features that are supported by `@Configuratio
[[features.external-config.typesafe-configuration-properties.vs-value-annotation.note]]
[NOTE]
====
-If you do want to use `@Value`, we recommend that you refer to property names using their canonical form (kebab-case using only lowercase letters).
-This will allow Spring Boot to use the same logic as it does when xref:features/external-config.adoc#features.external-config.typesafe-configuration-properties.relaxed-binding[relaxed binding] `@ConfigurationProperties`.
+If you do want to use javadoc:org.springframework.beans.factory.annotation.Value[format=annotation], we recommend that you refer to property names using their canonical form (kebab-case using only lowercase letters).
+This will allow Spring Boot to use the same logic as it does when xref:features/external-config.adoc#features.external-config.typesafe-configuration-properties.relaxed-binding[relaxed binding] javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation].
For example, `@Value("${demo.item-price}")` will pick up `demo.item-price` and `demo.itemPrice` forms from the `application.properties` file, as well as `DEMO_ITEMPRICE` from the system environment.
If you used `@Value("${demo.itemPrice}")` instead, `demo.item-price` and `DEMO_ITEMPRICE` would not be considered.
====
-If you define a set of configuration keys for your own components, we recommend you group them in a POJO annotated with `@ConfigurationProperties`.
+If you define a set of configuration keys for your own components, we recommend you group them in a POJO annotated with javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation].
Doing so will provide you with structured, type-safe object that you can inject into your own beans.
`SpEL` expressions from xref:features/external-config.adoc#features.external-config.files[application property files] are not processed at time of parsing these files and populating the environment.
-However, it is possible to write a `SpEL` expression in `@Value`.
-If the value of a property from an application property file is a `SpEL` expression, it will be evaluated when consumed through `@Value`.
+However, it is possible to write a `SpEL` expression in javadoc:org.springframework.beans.factory.annotation.Value[format=annotation].
+If the value of a property from an application property file is a `SpEL` expression, it will be evaluated when consumed through javadoc:org.springframework.beans.factory.annotation.Value[format=annotation].
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/internationalization.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/internationalization.adoc
index 13557b033f..48465d8946 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/internationalization.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/internationalization.adoc
@@ -6,7 +6,7 @@ By default, Spring Boot looks for the presence of a `messages` resource bundle a
NOTE: The auto-configuration applies when the default properties file for the configured resource bundle is available (`messages.properties` by default).
If your resource bundle contains only language-specific properties files, you are required to add the default.
-If no properties file is found that matches any of the configured base names, there will be no auto-configured `MessageSource`.
+If no properties file is found that matches any of the configured base names, there will be no auto-configured javadoc:org.springframework.context.MessageSource[].
The basename of the resource bundle as well as several other attributes can be configured using the `spring.messages` namespace, as shown in the following example:
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/json.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/json.adoc
index 9bcbed7219..8eb0a508ed 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/json.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/json.adoc
@@ -15,29 +15,29 @@ Jackson is the preferred and default library.
== Jackson
Auto-configuration for Jackson is provided and Jackson is part of `spring-boot-starter-json`.
-When Jackson is on the classpath an `ObjectMapper` bean is automatically configured.
-Several configuration properties are provided for xref:how-to:spring-mvc.adoc#howto.spring-mvc.customize-jackson-objectmapper[customizing the configuration of the `ObjectMapper`].
+When Jackson is on the classpath an javadoc:com.fasterxml.jackson.databind.ObjectMapper[] bean is automatically configured.
+Several configuration properties are provided for xref:how-to:spring-mvc.adoc#howto.spring-mvc.customize-jackson-objectmapper[customizing the configuration of the javadoc:com.fasterxml.jackson.databind.ObjectMapper[]].
[[features.json.jackson.custom-serializers-and-deserializers]]
=== Custom Serializers and Deserializers
-If you use Jackson to serialize and deserialize JSON data, you might want to write your own `JsonSerializer` and `JsonDeserializer` classes.
-Custom serializers are usually https://github.com/FasterXML/jackson-docs/wiki/JacksonHowToCustomSerializers[registered with Jackson through a module], but Spring Boot provides an alternative `@JsonComponent` annotation that makes it easier to directly register Spring Beans.
+If you use Jackson to serialize and deserialize JSON data, you might want to write your own javadoc:com.fasterxml.jackson.databind.JsonSerializer[] and javadoc:com.fasterxml.jackson.databind.JsonDeserializer[] classes.
+Custom serializers are usually https://github.com/FasterXML/jackson-docs/wiki/JacksonHowToCustomSerializers[registered with Jackson through a module], but Spring Boot provides an alternative javadoc:org.springframework.boot.jackson.JsonComponent[format=annotation] annotation that makes it easier to directly register Spring Beans.
-You can use the `@JsonComponent` annotation directly on `JsonSerializer`, `JsonDeserializer` or `KeyDeserializer` implementations.
+You can use the javadoc:org.springframework.boot.jackson.JsonComponent[format=annotation] annotation directly on javadoc:com.fasterxml.jackson.databind.JsonSerializer[], javadoc:com.fasterxml.jackson.databind.JsonDeserializer[] or javadoc:com.fasterxml.jackson.databind.KeyDeserializer[] implementations.
You can also use it on classes that contain serializers/deserializers as inner classes, as shown in the following example:
include-code::MyJsonComponent[]
-All `@JsonComponent` beans in the `ApplicationContext` are automatically registered with Jackson.
-Because `@JsonComponent` is meta-annotated with `@Component`, the usual component-scanning rules apply.
+All javadoc:org.springframework.boot.jackson.JsonComponent[format=annotation] beans in the javadoc:org.springframework.context.ApplicationContext[] are automatically registered with Jackson.
+Because javadoc:org.springframework.boot.jackson.JsonComponent[format=annotation] is meta-annotated with javadoc:org.springframework.stereotype.Component[format=annotation], the usual component-scanning rules apply.
Spring Boot also provides javadoc:org.springframework.boot.jackson.JsonObjectSerializer[] and javadoc:org.springframework.boot.jackson.JsonObjectDeserializer[] base classes that provide useful alternatives to the standard Jackson versions when serializing objects.
See javadoc:org.springframework.boot.jackson.JsonObjectSerializer[] and javadoc:org.springframework.boot.jackson.JsonObjectDeserializer[] in the API documentation for details.
-The example above can be rewritten to use `JsonObjectSerializer`/`JsonObjectDeserializer` as follows:
+The example above can be rewritten to use javadoc:org.springframework.boot.jackson.JsonObjectSerializer[]/`JsonObjectDeserializer` as follows:
include-code::object/MyJsonComponent[]
@@ -47,8 +47,8 @@ include-code::object/MyJsonComponent[]
=== Mixins
Jackson has support for mixins that can be used to mix additional annotations into those already declared on a target class.
-Spring Boot's Jackson auto-configuration will scan your application's packages for classes annotated with `@JsonMixin` and register them with the auto-configured `ObjectMapper`.
-The registration is performed by Spring Boot's `JsonMixinModule`.
+Spring Boot's Jackson auto-configuration will scan your application's packages for classes annotated with javadoc:org.springframework.boot.jackson.JsonMixin[format=annotation] and register them with the auto-configured javadoc:com.fasterxml.jackson.databind.ObjectMapper[].
+The registration is performed by Spring Boot's javadoc:org.springframework.boot.jackson.JsonMixinModule[].
@@ -56,9 +56,9 @@ The registration is performed by Spring Boot's `JsonMixinModule`.
== Gson
Auto-configuration for Gson is provided.
-When Gson is on the classpath a `Gson` bean is automatically configured.
+When Gson is on the classpath a javadoc:com.google.gson.Gson[] bean is automatically configured.
Several `+spring.gson.*+` configuration properties are provided for customizing the configuration.
-To take more control, one or more `GsonBuilderCustomizer` beans can be used.
+To take more control, one or more javadoc:org.springframework.boot.autoconfigure.gson.GsonBuilderCustomizer[] beans can be used.
@@ -66,5 +66,5 @@ To take more control, one or more `GsonBuilderCustomizer` beans can be used.
== JSON-B
Auto-configuration for JSON-B is provided.
-When the JSON-B API and an implementation are on the classpath a `Jsonb` bean will be automatically configured.
+When the JSON-B API and an implementation are on the classpath a javadoc:jakarta.json.bind.Jsonb[] bean will be automatically configured.
The preferred JSON-B implementation is Eclipse Yasson for which dependency management is provided.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/kotlin.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/kotlin.adoc
index 5bbaaa8923..a164da8f5c 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/kotlin.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/kotlin.adoc
@@ -33,8 +33,8 @@ TIP: These dependencies and plugins are provided by default if one bootstraps a
== Null-safety
One of Kotlin's key features is {url-kotlin-docs}/null-safety.html[null-safety].
-It deals with `null` values at compile time rather than deferring the problem to runtime and encountering a `NullPointerException`.
-This helps to eliminate a common source of bugs without paying the cost of wrappers like `Optional`.
+It deals with `null` values at compile time rather than deferring the problem to runtime and encountering a javadoc:java.lang.NullPointerException[].
+This helps to eliminate a common source of bugs without paying the cost of wrappers like javadoc:java.util.Optional[].
Kotlin also allows using functional constructs with nullable values as described in this https://www.baeldung.com/kotlin-null-safety[comprehensive guide to null-safety in Kotlin].
Although Java does not allow one to express null-safety in its type system, Spring Framework, Spring Data, and Reactor now provide null-safety of their API through tooling-friendly annotations.
@@ -92,7 +92,7 @@ runApplication(*args) {
Kotlin {url-kotlin-docs}/extensions.html[extensions] provide the ability to extend existing classes with additional functionality.
The Spring Boot Kotlin API makes use of these extensions to add new Kotlin specific conveniences to existing APIs.
-`TestRestTemplate` extensions, similar to those provided by Spring Framework for `RestOperations` in Spring Framework, are provided.
+javadoc:org.springframework.boot.test.web.client.TestRestTemplate[] extensions, similar to those provided by Spring Framework for javadoc:org.springframework.web.client.RestOperations[] in Spring Framework, are provided.
Among other things, the extensions make it possible to take advantage of Kotlin reified type parameters.
@@ -114,7 +114,7 @@ TIP: `org.jetbrains.kotlinx:kotlinx-coroutines-reactor` dependency is provided b
[[features.kotlin.configuration-properties]]
== @ConfigurationProperties
-`@ConfigurationProperties` when used in combination with xref:features/external-config.adoc#features.external-config.typesafe-configuration-properties.constructor-binding[constructor binding] supports data classes with immutable `val` properties as shown in the following example:
+javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] when used in combination with xref:features/external-config.adoc#features.external-config.typesafe-configuration-properties.constructor-binding[constructor binding] supports data classes with immutable `val` properties as shown in the following example:
[source,kotlin]
----
@@ -145,10 +145,10 @@ Note that some features (such as detecting the default value or deprecated items
While it is possible to use JUnit 4 to test Kotlin code, JUnit 5 is provided by default and is recommended.
JUnit 5 enables a test class to be instantiated once and reused for all of the class's tests.
-This makes it possible to use `@BeforeAll` and `@AfterAll` annotations on non-static methods, which is a good fit for Kotlin.
+This makes it possible to use javadoc:org.junit.jupiter.api.BeforeAll[format=annotation] and javadoc:org.junit.jupiter.api.AfterAll[format=annotation] annotations on non-static methods, which is a good fit for Kotlin.
To mock Kotlin classes, https://mockk.io/[MockK] is recommended.
-If you need the `MockK` equivalent of the Mockito specific xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.mocking-beans[`@MockBean` and `@SpyBean` annotations], you can use https://github.com/Ninja-Squad/springmockk[SpringMockK] which provides similar `@MockkBean` and `@SpykBean` annotations.
+If you need the `MockK` equivalent of the Mockito specific xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.mocking-beans[`@MockBean` and javadoc:org.springframework.boot.test.mock.mockito.SpyBean[format=annotation] annotations], you can use https://github.com/Ninja-Squad/springmockk[SpringMockK] which provides similar `@MockkBean` and `@SpykBean` annotations.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/logging.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/logging.adoc
index 21982106a9..20defb85c5 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/logging.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/logging.adoc
@@ -199,7 +199,7 @@ The following rotation policy properties are supported:
[[features.logging.log-levels]]
== Log Levels
-All the supported logging systems can have the logger levels set in the Spring `Environment` (for example, in `application.properties`) by using `+logging.level.=+` where `level` is one of TRACE, DEBUG, INFO, WARN, ERROR, FATAL, or OFF.
+All the supported logging systems can have the logger levels set in the Spring javadoc:org.springframework.core.env.Environment[] (for example, in `application.properties`) by using `+logging.level.=+` where `level` is one of TRACE, DEBUG, INFO, WARN, ERROR, FATAL, or OFF.
The `root` logger can be configured by using `logging.level.root`.
The following example shows potential logging settings in `application.properties`:
@@ -228,7 +228,7 @@ If you need to configure logging for a class, you can use xref:features/external
It is often useful to be able to group related loggers together so that they can all be configured at the same time.
For example, you might commonly change the logging levels for _all_ Tomcat related loggers, but you can not easily remember top level packages.
-To help with this, Spring Boot allows you to define logging groups in your Spring `Environment`.
+To help with this, Spring Boot allows you to define logging groups in your Spring javadoc:org.springframework.core.env.Environment[].
For example, here is how you could define a "`tomcat`" group by adding it to your `application.properties`:
[configprops,yaml]
@@ -257,7 +257,7 @@ Spring Boot includes the following pre-defined logging groups that can be used o
| `org.springframework.core.codec`, `org.springframework.http`, `org.springframework.web`, `org.springframework.boot.actuate.endpoint.web`, `org.springframework.boot.web.servlet.ServletContextInitializerBeans`
| sql
-| `org.springframework.jdbc.core`, `org.hibernate.SQL`, `org.jooq.tools.LoggerListener`
+| `org.springframework.jdbc.core`, `org.hibernate.SQL`, javadoc:org.jooq.tools.LoggerListener[]
|===
@@ -285,13 +285,13 @@ logging:
[[features.logging.custom-log-configuration]]
== Custom Log Configuration
-The various logging systems can be activated by including the appropriate libraries on the classpath and can be further customized by providing a suitable configuration file in the root of the classpath or in a location specified by the following Spring `Environment` property: configprop:logging.config[].
+The various logging systems can be activated by including the appropriate libraries on the classpath and can be further customized by providing a suitable configuration file in the root of the classpath or in a location specified by the following Spring javadoc:org.springframework.core.env.Environment[] property: configprop:logging.config[].
-You can force Spring Boot to use a particular logging system by using the `org.springframework.boot.logging.LoggingSystem` system property.
-The value should be the fully qualified class name of a `LoggingSystem` implementation.
+You can force Spring Boot to use a particular logging system by using the javadoc:org.springframework.boot.logging.LoggingSystem[] system property.
+The value should be the fully qualified class name of a javadoc:org.springframework.boot.logging.LoggingSystem[] implementation.
You can also disable Spring Boot's logging configuration entirely by using a value of `none`.
-NOTE: Since logging is initialized *before* the `ApplicationContext` is created, it is not possible to control logging from `@PropertySources` in Spring `@Configuration` files.
+NOTE: Since logging is initialized *before* the javadoc:org.springframework.context.ApplicationContext[] is created, it is not possible to control logging from javadoc:org.springframework.context.annotation.PropertySources[format=annotation] in Spring javadoc:org.springframework.context.annotation.Configuration[format=annotation] files.
The only way to change the logging system or disable it entirely is through System properties.
Depending on your logging system, the following files are loaded:
@@ -315,7 +315,7 @@ If you use standard configuration locations, Spring cannot completely control lo
WARNING: There are known classloading issues with Java Util Logging that cause problems when running from an 'executable jar'.
We recommend that you avoid it when running from an 'executable jar' if at all possible.
-To help with the customization, some other properties are transferred from the Spring `Environment` to System properties.
+To help with the customization, some other properties are transferred from the Spring javadoc:org.springframework.core.env.Environment[] to System properties.
This allows the properties to be consumed by logging system configuration. For example, setting `logging.file.name` in `application.properties` or `LOGGING_FILE_NAME` as an environment variable will result in the `LOG_FILE` System property being set.
The properties that are transferred are described in the following table:
@@ -476,12 +476,12 @@ The following listing shows three sample profiles:
[[features.logging.logback-extensions.environment-properties]]
=== Environment Properties
-The `` tag lets you expose properties from the Spring `Environment` for use within Logback.
+The `` tag lets you expose properties from the Spring javadoc:org.springframework.core.env.Environment[] for use within Logback.
Doing so can be useful if you want to access values from your `application.properties` file in your Logback configuration.
The tag works in a similar way to Logback's standard `` tag.
-However, rather than specifying a direct `value`, you specify the `source` of the property (from the `Environment`).
+However, rather than specifying a direct `value`, you specify the `source` of the property (from the javadoc:org.springframework.core.env.Environment[]).
If you need to store the property somewhere other than in `local` scope, you can use the `scope` attribute.
-If you need a fallback value (in case the property is not set in the `Environment`), you can use the `defaultValue` attribute.
+If you need a fallback value (in case the property is not set in the javadoc:org.springframework.core.env.Environment[]), you can use the `defaultValue` attribute.
The following example shows how to expose properties for use within Logback:
[source,xml]
@@ -495,7 +495,7 @@ The following example shows how to expose properties for use within Logback:
----
NOTE: The `source` must be specified in kebab case (such as `my.property-name`).
-However, properties can be added to the `Environment` by using the relaxed rules.
+However, properties can be added to the javadoc:org.springframework.core.env.Environment[] by using the relaxed rules.
@@ -544,10 +544,10 @@ The following listing shows three sample profiles:
[[features.logging.log4j2-extensions.environment-properties-lookup]]
=== Environment Properties Lookup
-If you want to refer to properties from your Spring `Environment` within your Log4j2 configuration you can use `spring:` prefixed https://logging.apache.org/log4j/2.x/manual/lookups.html[lookups].
+If you want to refer to properties from your Spring javadoc:org.springframework.core.env.Environment[] within your Log4j2 configuration you can use `spring:` prefixed https://logging.apache.org/log4j/2.x/manual/lookups.html[lookups].
Doing so can be useful if you want to access values from your `application.properties` file in your Log4j2 configuration.
-The following example shows how to set a Log4j2 property named `applicationName` that reads `spring.application.name` from the Spring `Environment`:
+The following example shows how to set a Log4j2 property named `applicationName` that reads `spring.application.name` from the Spring javadoc:org.springframework.core.env.Environment[]:
[source,xml]
----
@@ -564,12 +564,12 @@ NOTE: The lookup key should be specified in kebab case (such as `my.property-nam
=== Log4j2 System Properties
Log4j2 supports a number of https://logging.apache.org/log4j/2.x/manual/systemproperties.html[System Properties] that can be used to configure various items.
-For example, the `log4j2.skipJansi` system property can be used to configure if the `ConsoleAppender` will try to use a https://github.com/fusesource/jansi[Jansi] output stream on Windows.
+For example, the `log4j2.skipJansi` system property can be used to configure if the javadoc:org.apache.logging.log4j.core.appender.ConsoleAppender[] will try to use a https://github.com/fusesource/jansi[Jansi] output stream on Windows.
-All system properties that are loaded after the Log4j2 initialization can be obtained from the Spring `Environment`.
-For example, you could add `log4j2.skipJansi=false` to your `application.properties` file to have the `ConsoleAppender` use Jansi on Windows.
+All system properties that are loaded after the Log4j2 initialization can be obtained from the Spring javadoc:org.springframework.core.env.Environment[].
+For example, you could add `log4j2.skipJansi=false` to your `application.properties` file to have the javadoc:org.apache.logging.log4j.core.appender.ConsoleAppender[] use Jansi on Windows.
-NOTE: The Spring `Environment` is only considered when system properties and OS environment variables do not contain the value being loaded.
+NOTE: The Spring javadoc:org.springframework.core.env.Environment[] is only considered when system properties and OS environment variables do not contain the value being loaded.
-WARNING: System properties that are loaded during early Log4j2 initialization cannot reference the Spring `Environment`.
+WARNING: System properties that are loaded during early Log4j2 initialization cannot reference the Spring javadoc:org.springframework.core.env.Environment[].
For example, the property Log4j2 uses to allow the default Log4j2 implementation to be chosen is used before the Spring Environment is available.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/profiles.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/profiles.adoc
index 5a26c5c7a4..c720b557bf 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/profiles.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/profiles.adoc
@@ -2,14 +2,14 @@
= Profiles
Spring Profiles provide a way to segregate parts of your application configuration and make it be available only in certain environments.
-Any `@Component`, `@Configuration` or `@ConfigurationProperties` can be marked with `@Profile` to limit when it is loaded, as shown in the following example:
+Any javadoc:org.springframework.stereotype.Component[format=annotation], javadoc:org.springframework.context.annotation.Configuration[format=annotation] or javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] can be marked with javadoc:org.springframework.context.annotation.Profile[format=annotation] to limit when it is loaded, as shown in the following example:
include-code::ProductionConfiguration[]
-NOTE: If `@ConfigurationProperties` beans are registered through `@EnableConfigurationProperties` instead of automatic scanning, the `@Profile` annotation needs to be specified on the `@Configuration` class that has the `@EnableConfigurationProperties` annotation.
-In the case where `@ConfigurationProperties` are scanned, `@Profile` can be specified on the `@ConfigurationProperties` class itself.
+NOTE: If javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans are registered through javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] instead of automatic scanning, the javadoc:org.springframework.context.annotation.Profile[format=annotation] annotation needs to be specified on the javadoc:org.springframework.context.annotation.Configuration[format=annotation] class that has the javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] annotation.
+In the case where javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] are scanned, javadoc:org.springframework.context.annotation.Profile[format=annotation] can be specified on the javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] class itself.
-You can use a configprop:spring.profiles.active[] `Environment` property to specify which profiles are active.
+You can use a configprop:spring.profiles.active[] javadoc:org.springframework.core.env.Environment[] property to specify which profiles are active.
You can specify the property in any of the ways described earlier in this chapter.
For example, you could include it in your `application.properties`, as shown in the following example:
@@ -23,7 +23,7 @@ spring:
You could also specify it on the command line by using the following switch: `--spring.profiles.active=dev,hsqldb`.
If no profile is active, a default profile is enabled.
-The name of the default profile is `default` and it can be tuned using the configprop:spring.profiles.default[] `Environment` property, as shown in the following example:
+The name of the default profile is `default` and it can be tuned using the configprop:spring.profiles.default[] javadoc:org.springframework.core.env.Environment[] property, as shown in the following example:
[configprops,yaml]
----
@@ -58,12 +58,12 @@ spring:
[[features.profiles.adding-active-profiles]]
== Adding Active Profiles
-The configprop:spring.profiles.active[] property follows the same ordering rules as other properties: The highest `PropertySource` wins.
+The configprop:spring.profiles.active[] property follows the same ordering rules as other properties: The highest javadoc:org.springframework.core.env.PropertySource[] wins.
This means that you can specify active profiles in `application.properties` and then *replace* them by using the command line switch.
Sometimes, it is useful to have properties that *add* to the active profiles rather than replace them.
The `spring.profiles.include` property can be used to add active profiles on top of those activated by the configprop:spring.profiles.active[] property.
-The `SpringApplication` entry point also has a Java API for setting additional profiles.
+The javadoc:org.springframework.boot.SpringApplication[] entry point also has a Java API for setting additional profiles.
See the `setAdditionalProfiles()` method in javadoc:org.springframework.boot.SpringApplication[].
For example, when an application with the following properties is run, the common and local profiles will be activated even when it runs using the `--spring.profiles.active` switch:
@@ -115,12 +115,12 @@ This means it cannot be included in xref:features/external-config.adoc#features.
== Programmatically Setting Profiles
You can programmatically set active profiles by calling `SpringApplication.setAdditionalProfiles(...)` before your application runs.
-It is also possible to activate profiles by using Spring's `ConfigurableEnvironment` interface.
+It is also possible to activate profiles by using Spring's javadoc:org.springframework.core.env.ConfigurableEnvironment[] interface.
[[features.profiles.profile-specific-configuration-files]]
== Profile-specific Configuration Files
-Profile-specific variants of both `application.properties` (or `application.yaml`) and files referenced through `@ConfigurationProperties` are considered as files and loaded.
+Profile-specific variants of both `application.properties` (or `application.yaml`) and files referenced through javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] are considered as files and loaded.
See xref:features/external-config.adoc#features.external-config.files.profile-specific[] for details.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/spring-application.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/spring-application.adoc
index 24453e6bb5..30e54e878b 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/spring-application.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/spring-application.adoc
@@ -1,7 +1,7 @@
[[features.spring-application]]
= SpringApplication
-The `SpringApplication` class provides a convenient way to bootstrap a Spring application that is started from a `main()` method.
+The javadoc:org.springframework.boot.SpringApplication[] class provides a convenient way to bootstrap a Spring application that is started from a `main()` method.
In many situations, you can delegate to the static javadoc:org.springframework.boot.SpringApplication#run(java.lang.Class,java.lang.String...)[] method, as shown in the following example:
include-code::MyApplication[]
@@ -21,14 +21,14 @@ The application version is determined using the implementation version from the
Startup information logging can be turned off by setting `spring.main.log-startup-info` to `false`.
This will also turn off logging of the application's active profiles.
-TIP: To add additional logging during startup, you can override `logStartupInfo(boolean)` in a subclass of `SpringApplication`.
+TIP: To add additional logging during startup, you can override `logStartupInfo(boolean)` in a subclass of javadoc:org.springframework.boot.SpringApplication[].
[[features.spring-application.startup-failure]]
== Startup Failure
-If your application fails to start, registered `FailureAnalyzer` beans get a chance to provide a dedicated error message and a concrete action to fix the problem.
+If your application fails to start, registered javadoc:org.springframework.boot.diagnostics.FailureAnalyzer[] beans get a chance to provide a dedicated error message and a concrete action to fix the problem.
For instance, if you start a web application on port `8080` and that port is already in use, you should see something similar to the following message:
[source]
@@ -46,10 +46,10 @@ Action:
Identify and stop the process that is listening on port 8080 or configure this application to listen on another port.
----
-NOTE: Spring Boot provides numerous `FailureAnalyzer` implementations, and you can xref:how-to:application.adoc#howto.application.failure-analyzer[add your own].
+NOTE: Spring Boot provides numerous javadoc:org.springframework.boot.diagnostics.FailureAnalyzer[] implementations, and you can xref:how-to:application.adoc#howto.application.failure-analyzer[add your own].
If no failure analyzers are able to handle the exception, you can still display the full conditions report to better understand what went wrong.
-To do so, you need to xref:features/external-config.adoc[enable the `debug` property] or xref:features/logging.adoc#features.logging.log-levels[enable `DEBUG` logging] for `org.springframework.boot.autoconfigure.logging.ConditionEvaluationReportLoggingListener`.
+To do so, you need to xref:features/external-config.adoc[enable the `debug` property] or xref:features/logging.adoc#features.logging.log-levels[enable `DEBUG` logging] for javadoc:org.springframework.boot.autoconfigure.logging.ConditionEvaluationReportLoggingListener[].
For instance, if you are running your application by using `java -jar`, you can enable the `debug` property as follows:
@@ -63,7 +63,7 @@ $ java -jar myproject-0.0.1-SNAPSHOT.jar --debug
[[features.spring-application.lazy-initialization]]
== Lazy Initialization
-`SpringApplication` allows an application to be initialized lazily.
+javadoc:org.springframework.boot.SpringApplication[] allows an application to be initialized lazily.
When lazy initialization is enabled, beans are created as they are needed rather than during application startup.
As a result, enabling lazy initialization can reduce the time that it takes your application to start.
In a web application, enabling lazy initialization will result in many web-related beans not being initialized until an HTTP request is received.
@@ -73,7 +73,7 @@ If a misconfigured bean is initialized lazily, a failure will no longer occur du
Care must also be taken to ensure that the JVM has sufficient memory to accommodate all of the application's beans and not just those that are initialized during startup.
For these reasons, lazy initialization is not enabled by default and it is recommended that fine-tuning of the JVM's heap size is done before enabling lazy initialization.
-Lazy initialization can be enabled programmatically using the `lazyInitialization` method on `SpringApplicationBuilder` or the `setLazyInitialization` method on `SpringApplication`.
+Lazy initialization can be enabled programmatically using the `lazyInitialization` method on javadoc:org.springframework.boot.builder.SpringApplicationBuilder[] or the `setLazyInitialization` method on javadoc:org.springframework.boot.SpringApplication[].
Alternatively, it can be enabled using the configprop:spring.main.lazy-initialization[] property as shown in the following example:
[configprops,yaml]
@@ -93,7 +93,7 @@ TIP: If you want to disable lazy initialization for certain beans while using la
The banner that is printed on start up can be changed by adding a `banner.txt` file to your classpath or by setting the configprop:spring.banner.location[] property to the location of such a file.
If the file has an encoding other than UTF-8, you can set `spring.banner.charset`.
-Inside your `banner.txt` file, you can use any key available in the `Environment` as well as any of the following placeholders:
+Inside your `banner.txt` file, you can use any key available in the javadoc:org.springframework.core.env.Environment[] as well as any of the following placeholders:
.Banner variables
|===
@@ -125,7 +125,7 @@ Inside your `banner.txt` file, you can use any key available in the `Environment
|===
TIP: The `SpringApplication.setBanner(...)` method can be used if you want to generate a banner programmatically.
-Use the `org.springframework.boot.Banner` interface and implement your own `printBanner()` method.
+Use the javadoc:org.springframework.boot.Banner[] interface and implement your own `printBanner()` method.
You can also use the configprop:spring.main.banner-mode[] property to determine if the banner has to be printed on javadoc:java.lang.System#out[] (`console`), sent to the configured logger (`log`), or not produced at all (`off`).
@@ -146,15 +146,15 @@ This will initialize the `application.*` banner properties before building the c
[[features.spring-application.customizing-spring-application]]
== Customizing SpringApplication
-If the `SpringApplication` defaults are not to your taste, you can instead create a local instance and customize it.
+If the javadoc:org.springframework.boot.SpringApplication[] defaults are not to your taste, you can instead create a local instance and customize it.
For example, to turn off the banner, you could write:
include-code::MyApplication[]
-NOTE: The constructor arguments passed to `SpringApplication` are configuration sources for Spring beans.
-In most cases, these are references to `@Configuration` classes, but they could also be direct references `@Component` classes.
+NOTE: The constructor arguments passed to javadoc:org.springframework.boot.SpringApplication[] are configuration sources for Spring beans.
+In most cases, these are references to javadoc:org.springframework.context.annotation.Configuration[format=annotation] classes, but they could also be direct references javadoc:org.springframework.stereotype.Component[format=annotation] classes.
-It is also possible to configure the `SpringApplication` by using an `application.properties` file.
+It is also possible to configure the javadoc:org.springframework.boot.SpringApplication[] by using an `application.properties` file.
See xref:features/external-config.adoc[] for details.
For a complete list of the configuration options, see the javadoc:org.springframework.boot.SpringApplication[] API documentation.
@@ -164,14 +164,14 @@ For a complete list of the configuration options, see the javadoc:org.springfram
[[features.spring-application.fluent-builder-api]]
== Fluent Builder API
-If you need to build an `ApplicationContext` hierarchy (multiple contexts with a parent/child relationship) or if you prefer using a fluent builder API, you can use the `SpringApplicationBuilder`.
+If you need to build an javadoc:org.springframework.context.ApplicationContext[] hierarchy (multiple contexts with a parent/child relationship) or if you prefer using a fluent builder API, you can use the javadoc:org.springframework.boot.builder.SpringApplicationBuilder[].
-The `SpringApplicationBuilder` lets you chain together multiple method calls and includes `parent` and `child` methods that let you create a hierarchy, as shown in the following example:
+The javadoc:org.springframework.boot.builder.SpringApplicationBuilder[] lets you chain together multiple method calls and includes `parent` and `child` methods that let you create a hierarchy, as shown in the following example:
include-code::MyApplication[tag=*]
-NOTE: There are some restrictions when creating an `ApplicationContext` hierarchy.
-For example, Web components *must* be contained within the child context, and the same `Environment` is used for both parent and child contexts.
+NOTE: There are some restrictions when creating an javadoc:org.springframework.context.ApplicationContext[] hierarchy.
+For example, Web components *must* be contained within the child context, and the same javadoc:org.springframework.core.env.Environment[] is used for both parent and child contexts.
See the javadoc:org.springframework.boot.builder.SpringApplicationBuilder[] API documentation for full details.
@@ -183,7 +183,7 @@ When deployed on platforms, applications can provide information about their ava
Spring Boot includes out-of-the box support for the commonly used "`liveness`" and "`readiness`" availability states.
If you are using Spring Boot's "`actuator`" support then these states are exposed as health endpoint groups.
-In addition, you can also obtain availability states by injecting the `ApplicationAvailability` interface into your own beans.
+In addition, you can also obtain availability states by injecting the javadoc:org.springframework.boot.availability.ApplicationAvailability[] interface into your own beans.
@@ -196,7 +196,7 @@ A broken "`Liveness`" state means that the application is in a state that it can
NOTE: In general, the "Liveness" state should not be based on external checks, such as xref:actuator/endpoints.adoc#actuator.endpoints.health[health checks].
If it did, a failing external system (a database, a Web API, an external cache) would trigger massive restarts and cascading failures across the platform.
-The internal state of Spring Boot applications is mostly represented by the Spring `ApplicationContext`.
+The internal state of Spring Boot applications is mostly represented by the Spring javadoc:org.springframework.context.ApplicationContext[].
If the application context has started successfully, Spring Boot assumes that the application is in a valid state.
An application is considered live as soon as the context has been refreshed, see xref:features/spring-application.adoc#features.spring-application.application-events-and-listeners[Spring Boot application lifecycle and related Application Events].
@@ -207,18 +207,18 @@ An application is considered live as soon as the context has been refreshed, see
The "`Readiness`" state of an application tells whether the application is ready to handle traffic.
A failing "`Readiness`" state tells the platform that it should not route traffic to the application for now.
-This typically happens during startup, while `CommandLineRunner` and `ApplicationRunner` components are being processed, or at any time if the application decides that it is too busy for additional traffic.
+This typically happens during startup, while javadoc:org.springframework.boot.CommandLineRunner[] and javadoc:org.springframework.boot.ApplicationRunner[] components are being processed, or at any time if the application decides that it is too busy for additional traffic.
An application is considered ready as soon as application and command-line runners have been called, see xref:features/spring-application.adoc#features.spring-application.application-events-and-listeners[Spring Boot application lifecycle and related Application Events].
-TIP: Tasks expected to run during startup should be executed by `CommandLineRunner` and `ApplicationRunner` components instead of using Spring component lifecycle callbacks such as `@PostConstruct`.
+TIP: Tasks expected to run during startup should be executed by javadoc:org.springframework.boot.CommandLineRunner[] and javadoc:org.springframework.boot.ApplicationRunner[] components instead of using Spring component lifecycle callbacks such as javadoc:jakarta.annotation.PostConstruct[format=annotation].
[[features.spring-application.application-availability.managing]]
=== Managing the Application Availability State
-Application components can retrieve the current availability state at any time, by injecting the `ApplicationAvailability` interface and calling methods on it.
+Application components can retrieve the current availability state at any time, by injecting the javadoc:org.springframework.boot.availability.ApplicationAvailability[] interface and calling methods on it.
More often, applications will want to listen to state updates or update the state of the application.
For example, we can export the "Readiness" state of the application to a file so that a Kubernetes "exec Probe" can look at this file:
@@ -237,14 +237,14 @@ You can get more guidance about xref:how-to:deployment/cloud.adoc#howto.deployme
[[features.spring-application.application-events-and-listeners]]
== Application Events and Listeners
-In addition to the usual Spring Framework events, such as javadoc:{url-spring-framework-javadoc}/org.springframework.context.event.ContextRefreshedEvent[], a `SpringApplication` sends some additional application events.
+In addition to the usual Spring Framework events, such as javadoc:{url-spring-framework-javadoc}/org.springframework.context.event.ContextRefreshedEvent[], a javadoc:org.springframework.boot.SpringApplication[] sends some additional application events.
[NOTE]
====
-Some events are actually triggered before the `ApplicationContext` is created, so you cannot register a listener on those as a `@Bean`.
+Some events are actually triggered before the javadoc:org.springframework.context.ApplicationContext[] is created, so you cannot register a listener on those as a javadoc:org.springframework.context.annotation.Bean[format=annotation].
You can register them with the `SpringApplication.addListeners(...)` method or the `SpringApplicationBuilder.listeners(...)` method.
-If you want those listeners to be registered automatically, regardless of the way the application is created, you can add a `META-INF/spring.factories` file to your project and reference your listener(s) by using the `org.springframework.context.ApplicationListener` key, as shown in the following example:
+If you want those listeners to be registered automatically, regardless of the way the application is created, you can add a `META-INF/spring.factories` file to your project and reference your listener(s) by using the javadoc:org.springframework.context.ApplicationListener[] key, as shown in the following example:
[source]
----
@@ -255,22 +255,22 @@ org.springframework.context.ApplicationListener=com.example.project.MyListener
Application events are sent in the following order, as your application runs:
-. An `ApplicationStartingEvent` is sent at the start of a run but before any processing, except for the registration of listeners and initializers.
-. An `ApplicationEnvironmentPreparedEvent` is sent when the `Environment` to be used in the context is known but before the context is created.
-. An `ApplicationContextInitializedEvent` is sent when the `ApplicationContext` is prepared and ApplicationContextInitializers have been called but before any bean definitions are loaded.
-. An `ApplicationPreparedEvent` is sent just before the refresh is started but after bean definitions have been loaded.
-. An `ApplicationStartedEvent` is sent after the context has been refreshed but before any application and command-line runners have been called.
-. An `AvailabilityChangeEvent` is sent right after with javadoc:org.springframework.boot.availability.LivenessState#CORRECT[] to indicate that the application is considered as live.
-. An `ApplicationReadyEvent` is sent after any xref:features/spring-application.adoc#features.spring-application.command-line-runner[application and command-line runners] have been called.
-. An `AvailabilityChangeEvent` is sent right after with javadoc:org.springframework.boot.availability.ReadinessState#ACCEPTING_TRAFFIC[] to indicate that the application is ready to service requests.
-. An `ApplicationFailedEvent` is sent if there is an exception on startup.
+. An javadoc:org.springframework.boot.context.event.ApplicationStartingEvent[] is sent at the start of a run but before any processing, except for the registration of listeners and initializers.
+. An javadoc:org.springframework.boot.context.event.ApplicationEnvironmentPreparedEvent[] is sent when the javadoc:org.springframework.core.env.Environment[] to be used in the context is known but before the context is created.
+. An javadoc:org.springframework.boot.context.event.ApplicationContextInitializedEvent[] is sent when the javadoc:org.springframework.context.ApplicationContext[] is prepared and ApplicationContextInitializers have been called but before any bean definitions are loaded.
+. An javadoc:org.springframework.boot.context.event.ApplicationPreparedEvent[] is sent just before the refresh is started but after bean definitions have been loaded.
+. An javadoc:org.springframework.boot.context.event.ApplicationStartedEvent[] is sent after the context has been refreshed but before any application and command-line runners have been called.
+. An javadoc:org.springframework.boot.availability.AvailabilityChangeEvent[] is sent right after with javadoc:org.springframework.boot.availability.LivenessState#CORRECT[] to indicate that the application is considered as live.
+. An javadoc:org.springframework.boot.context.event.ApplicationReadyEvent[] is sent after any xref:features/spring-application.adoc#features.spring-application.command-line-runner[application and command-line runners] have been called.
+. An javadoc:org.springframework.boot.availability.AvailabilityChangeEvent[] is sent right after with javadoc:org.springframework.boot.availability.ReadinessState#ACCEPTING_TRAFFIC[] to indicate that the application is ready to service requests.
+. An javadoc:org.springframework.boot.context.event.ApplicationFailedEvent[] is sent if there is an exception on startup.
-The above list only includes ``SpringApplicationEvent``s that are tied to a `SpringApplication`.
-In addition to these, the following events are also published after `ApplicationPreparedEvent` and before `ApplicationStartedEvent`:
+The above list only includes ``SpringApplicationEvent``s that are tied to a javadoc:org.springframework.boot.SpringApplication[].
+In addition to these, the following events are also published after javadoc:org.springframework.boot.context.event.ApplicationPreparedEvent[] and before javadoc:org.springframework.boot.context.event.ApplicationStartedEvent[]:
-- A `WebServerInitializedEvent` is sent after the `WebServer` is ready.
- `ServletWebServerInitializedEvent` and `ReactiveWebServerInitializedEvent` are the servlet and reactive variants respectively.
-- A `ContextRefreshedEvent` is sent when an `ApplicationContext` is refreshed.
+- A javadoc:org.springframework.boot.web.context.WebServerInitializedEvent[] is sent after the javadoc:org.springframework.boot.web.server.WebServer[] is ready.
+ javadoc:org.springframework.boot.web.servlet.context.ServletWebServerInitializedEvent[] and javadoc:org.springframework.boot.web.reactive.context.ReactiveWebServerInitializedEvent[] are the servlet and reactive variants respectively.
+- A javadoc:org.springframework.context.event.ContextRefreshedEvent[] is sent when an javadoc:org.springframework.context.ApplicationContext[] is refreshed.
TIP: You often need not use application events, but it can be handy to know that they exist.
Internally, Spring Boot uses events to handle a variety of tasks.
@@ -280,79 +280,79 @@ Consider using xref:features/spring-application.adoc#features.spring-application
Application events are sent by using Spring Framework's event publishing mechanism.
Part of this mechanism ensures that an event published to the listeners in a child context is also published to the listeners in any ancestor contexts.
-As a result of this, if your application uses a hierarchy of `SpringApplication` instances, a listener may receive multiple instances of the same type of application event.
+As a result of this, if your application uses a hierarchy of javadoc:org.springframework.boot.SpringApplication[] instances, a listener may receive multiple instances of the same type of application event.
To allow your listener to distinguish between an event for its context and an event for a descendant context, it should request that its application context is injected and then compare the injected context with the context of the event.
-The context can be injected by implementing `ApplicationContextAware` or, if the listener is a bean, by using `@Autowired`.
+The context can be injected by implementing javadoc:org.springframework.context.ApplicationContextAware[] or, if the listener is a bean, by using javadoc:org.springframework.beans.factory.annotation.Autowired[format=annotation].
[[features.spring-application.web-environment]]
== Web Environment
-A `SpringApplication` attempts to create the right type of `ApplicationContext` on your behalf.
-The algorithm used to determine a `WebApplicationType` is the following:
+A javadoc:org.springframework.boot.SpringApplication[] attempts to create the right type of javadoc:org.springframework.context.ApplicationContext[] on your behalf.
+The algorithm used to determine a javadoc:org.springframework.boot.WebApplicationType[] is the following:
-* If Spring MVC is present, an `AnnotationConfigServletWebServerApplicationContext` is used
-* If Spring MVC is not present and Spring WebFlux is present, an `AnnotationConfigReactiveWebServerApplicationContext` is used
-* Otherwise, `AnnotationConfigApplicationContext` is used
+* If Spring MVC is present, an javadoc:org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext[] is used
+* If Spring MVC is not present and Spring WebFlux is present, an javadoc:org.springframework.boot.web.reactive.context.AnnotationConfigReactiveWebServerApplicationContext[] is used
+* Otherwise, javadoc:org.springframework.context.annotation.AnnotationConfigApplicationContext[] is used
-This means that if you are using Spring MVC and the new `WebClient` from Spring WebFlux in the same application, Spring MVC will be used by default.
+This means that if you are using Spring MVC and the new javadoc:org.springframework.web.reactive.function.client.WebClient[] from Spring WebFlux in the same application, Spring MVC will be used by default.
You can override that easily by calling `setWebApplicationType(WebApplicationType)`.
-It is also possible to take complete control of the `ApplicationContext` type that is used by calling `setApplicationContextFactory(...)`.
+It is also possible to take complete control of the javadoc:org.springframework.context.ApplicationContext[] type that is used by calling `setApplicationContextFactory(...)`.
-TIP: It is often desirable to call `setWebApplicationType(WebApplicationType.NONE)` when using `SpringApplication` within a JUnit test.
+TIP: It is often desirable to call `setWebApplicationType(WebApplicationType.NONE)` when using javadoc:org.springframework.boot.SpringApplication[] within a JUnit test.
[[features.spring-application.application-arguments]]
== Accessing Application Arguments
-If you need to access the application arguments that were passed to `SpringApplication.run(...)`, you can inject a `org.springframework.boot.ApplicationArguments` bean.
-The `ApplicationArguments` interface provides access to both the raw `String[]` arguments as well as parsed `option` and `non-option` arguments, as shown in the following example:
+If you need to access the application arguments that were passed to `SpringApplication.run(...)`, you can inject a javadoc:org.springframework.boot.ApplicationArguments[] bean.
+The javadoc:org.springframework.boot.ApplicationArguments[] interface provides access to both the raw `String[]` arguments as well as parsed `option` and `non-option` arguments, as shown in the following example:
include-code::MyBean[]
-TIP: Spring Boot also registers a `CommandLinePropertySource` with the Spring `Environment`.
-This lets you also inject single application arguments by using the `@Value` annotation.
+TIP: Spring Boot also registers a javadoc:org.springframework.core.env.CommandLinePropertySource[] with the Spring javadoc:org.springframework.core.env.Environment[].
+This lets you also inject single application arguments by using the javadoc:org.springframework.beans.factory.annotation.Value[format=annotation] annotation.
[[features.spring-application.command-line-runner]]
== Using the ApplicationRunner or CommandLineRunner
-If you need to run some specific code once the `SpringApplication` has started, you can implement the `ApplicationRunner` or `CommandLineRunner` interfaces.
+If you need to run some specific code once the javadoc:org.springframework.boot.SpringApplication[] has started, you can implement the javadoc:org.springframework.boot.ApplicationRunner[] or javadoc:org.springframework.boot.CommandLineRunner[] interfaces.
Both interfaces work in the same way and offer a single `run` method, which is called just before `SpringApplication.run(...)` completes.
NOTE: This contract is well suited for tasks that should run after application startup but before it starts accepting traffic.
-The `CommandLineRunner` interfaces provides access to application arguments as a string array, whereas the `ApplicationRunner` uses the `ApplicationArguments` interface discussed earlier.
-The following example shows a `CommandLineRunner` with a `run` method:
+The javadoc:org.springframework.boot.CommandLineRunner[] interfaces provides access to application arguments as a string array, whereas the javadoc:org.springframework.boot.ApplicationRunner[] uses the javadoc:org.springframework.boot.ApplicationArguments[] interface discussed earlier.
+The following example shows a javadoc:org.springframework.boot.CommandLineRunner[] with a `run` method:
include-code::MyCommandLineRunner[]
-If several `CommandLineRunner` or `ApplicationRunner` beans are defined that must be called in a specific order, you can additionally implement the `org.springframework.core.Ordered` interface or use the `org.springframework.core.annotation.Order` annotation.
+If several javadoc:org.springframework.boot.CommandLineRunner[] or javadoc:org.springframework.boot.ApplicationRunner[] beans are defined that must be called in a specific order, you can additionally implement the javadoc:org.springframework.core.Ordered[] interface or use the javadoc:org.springframework.core.annotation.Order[] annotation.
[[features.spring-application.application-exit]]
== Application Exit
-Each `SpringApplication` registers a shutdown hook with the JVM to ensure that the `ApplicationContext` closes gracefully on exit.
-All the standard Spring lifecycle callbacks (such as the `DisposableBean` interface or the `@PreDestroy` annotation) can be used.
+Each javadoc:org.springframework.boot.SpringApplication[] registers a shutdown hook with the JVM to ensure that the javadoc:org.springframework.context.ApplicationContext[] closes gracefully on exit.
+All the standard Spring lifecycle callbacks (such as the javadoc:org.springframework.beans.factory.DisposableBean[] interface or the javadoc:jakarta.annotation.PreDestroy[format=annotation] annotation) can be used.
-In addition, beans may implement the `org.springframework.boot.ExitCodeGenerator` interface if they wish to return a specific exit code when `SpringApplication.exit()` is called.
+In addition, beans may implement the javadoc:org.springframework.boot.ExitCodeGenerator[] interface if they wish to return a specific exit code when `SpringApplication.exit()` is called.
This exit code can then be passed to `System.exit()` to return it as a status code, as shown in the following example:
include-code::MyApplication[]
-Also, the `ExitCodeGenerator` interface may be implemented by exceptions.
+Also, the javadoc:org.springframework.boot.ExitCodeGenerator[] interface may be implemented by exceptions.
When such an exception is encountered, Spring Boot returns the exit code provided by the implemented `getExitCode()` method.
-If there is more than one `ExitCodeGenerator`, the first non-zero exit code that is generated is used.
-To control the order in which the generators are called, additionally implement the `org.springframework.core.Ordered` interface or use the `org.springframework.core.annotation.Order` annotation.
+If there is more than one javadoc:org.springframework.boot.ExitCodeGenerator[], the first non-zero exit code that is generated is used.
+To control the order in which the generators are called, additionally implement the javadoc:org.springframework.core.Ordered[] interface or use the javadoc:org.springframework.core.annotation.Order[] annotation.
@@ -360,7 +360,7 @@ To control the order in which the generators are called, additionally implement
== Admin Features
It is possible to enable admin-related features for the application by specifying the configprop:spring.application.admin.enabled[] property.
-This exposes the javadoc:org.springframework.boot.admin.SpringApplicationAdminMXBean[] on the platform `MBeanServer`.
+This exposes the javadoc:org.springframework.boot.admin.SpringApplicationAdminMXBean[] on the platform javadoc:javax.management.MBeanServer[].
You could use this feature to administer your Spring Boot application remotely.
This feature could also be useful for any service wrapper implementation.
@@ -371,17 +371,17 @@ TIP: If you want to know on which HTTP port the application is running, get the
[[features.spring-application.startup-tracking]]
== Application Startup tracking
-During the application startup, the `SpringApplication` and the `ApplicationContext` perform many tasks related to the application lifecycle,
+During the application startup, the javadoc:org.springframework.boot.SpringApplication[] and the javadoc:org.springframework.context.ApplicationContext[] perform many tasks related to the application lifecycle,
the beans lifecycle or even processing application events.
-With javadoc:{url-spring-framework-javadoc}/org.springframework.core.metrics.ApplicationStartup[], Spring Framework {url-spring-framework-docs}/core/beans/context-introduction.html#context-functionality-startup[allows you to track the application startup sequence with `StartupStep` objects].
+With javadoc:{url-spring-framework-javadoc}/org.springframework.core.metrics.ApplicationStartup[], Spring Framework {url-spring-framework-docs}/core/beans/context-introduction.html#context-functionality-startup[allows you to track the application startup sequence with javadoc:org.springframework.core.metrics.StartupStep[] objects].
This data can be collected for profiling purposes, or just to have a better understanding of an application startup process.
-You can choose an `ApplicationStartup` implementation when setting up the `SpringApplication` instance.
-For example, to use the `BufferingApplicationStartup`, you could write:
+You can choose an javadoc:org.springframework.core.metrics.ApplicationStartup[] implementation when setting up the javadoc:org.springframework.boot.SpringApplication[] instance.
+For example, to use the javadoc:org.springframework.boot.context.metrics.buffering.BufferingApplicationStartup[], you could write:
include-code::MyApplication[]
-The first available implementation, `FlightRecorderApplicationStartup` is provided by Spring Framework.
+The first available implementation, javadoc:org.springframework.core.metrics.jfr.FlightRecorderApplicationStartup[] is provided by Spring Framework.
It adds Spring-specific startup events to a Java Flight Recorder session and is meant for profiling applications and correlating their Spring context lifecycle with JVM events (such as allocations, GCs, class loading...).
Once configured, you can record data by running the application with the Flight Recorder enabled:
@@ -390,8 +390,8 @@ Once configured, you can record data by running the application with the Flight
$ java -XX:StartFlightRecording:filename=recording.jfr,duration=10s -jar demo.jar
----
-Spring Boot ships with the `BufferingApplicationStartup` variant; this implementation is meant for buffering the startup steps and draining them into an external metrics system.
-Applications can ask for the bean of type `BufferingApplicationStartup` in any component.
+Spring Boot ships with the javadoc:org.springframework.boot.context.metrics.buffering.BufferingApplicationStartup[] variant; this implementation is meant for buffering the startup steps and draining them into an external metrics system.
+Applications can ask for the bean of type javadoc:org.springframework.boot.context.metrics.buffering.BufferingApplicationStartup[] in any component.
Spring Boot can also be configured to expose a xref:api:rest/actuator/startup.adoc[`startup` endpoint] that provides this information as a JSON document.
@@ -410,7 +410,7 @@ That's because virtual threads are scheduled on a JVM wide platform thread pool
WARNING: One side effect of virtual threads is that they are daemon threads.
A JVM will exit if all of its threads are daemon threads.
-This behavior can be a problem when you rely on `@Scheduled` beans, for example, to keep your application alive.
+This behavior can be a problem when you rely on javadoc:org.springframework.scheduling.annotation.Scheduled[format=annotation] beans, for example, to keep your application alive.
If you use virtual threads, the scheduler thread is a virtual thread and therefore a daemon thread and won't keep the JVM alive.
This not only affects scheduling and can be the case with other technologies too.
To keep the JVM running in all cases, it is recommended to set the property configprop:spring.main.keep-alive[] to `true`.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/ssl.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/ssl.adoc
index 23fe8531b2..dab3b00d10 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/ssl.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/ssl.adoc
@@ -126,18 +126,18 @@ See the sections on xref:how-to:webserver.adoc#howto.webserver.configure-ssl[emb
[[features.ssl.bundles]]
== Using SSL Bundles
-Spring Boot auto-configures a bean of type `SslBundles` that provides access to each of the named bundles configured using the `spring.ssl.bundle` properties.
+Spring Boot auto-configures a bean of type javadoc:org.springframework.boot.ssl.SslBundles[] that provides access to each of the named bundles configured using the `spring.ssl.bundle` properties.
-An `SslBundle` can be retrieved from the auto-configured `SslBundles` bean and used to create objects that are used to configure SSL connectivity in client libraries.
-The `SslBundle` provides a layered approach of obtaining these SSL objects:
+An javadoc:org.springframework.boot.ssl.SslBundle[] can be retrieved from the auto-configured javadoc:org.springframework.boot.ssl.SslBundles[] bean and used to create objects that are used to configure SSL connectivity in client libraries.
+The javadoc:org.springframework.boot.ssl.SslBundle[] provides a layered approach of obtaining these SSL objects:
-- `getStores()` provides access to the key store and trust store `java.security.KeyStore` instances as well as any required key store password.
-- `getManagers()` provides access to the `java.net.ssl.KeyManagerFactory` and `java.net.ssl.TrustManagerFactory` instances as well as the `java.net.ssl.KeyManager` and `java.net.ssl.TrustManager` arrays that they create.
-- `createSslContext()` provides a convenient way to obtain a new `java.net.ssl.SSLContext` instance.
+- `getStores()` provides access to the key store and trust store javadoc:java.security.KeyStore[] instances as well as any required key store password.
+- `getManagers()` provides access to the javadoc:javax.net.ssl.KeyManagerFactory[] and javadoc:javax.net.ssl.TrustManagerFactory[] instances as well as the javadoc:javax.net.ssl.KeyManager[] and javadoc:javax.net.ssl.TrustManager[] arrays that they create.
+- `createSslContext()` provides a convenient way to obtain a new javadoc:javax.net.ssl.SSLContext[] instance.
-In addition, the `SslBundle` provides details about the key being used, the protocol to use and any option that should be applied to the SSL engine.
+In addition, the javadoc:org.springframework.boot.ssl.SslBundle[] provides details about the key being used, the protocol to use and any option that should be applied to the SSL engine.
-The following example shows retrieving an `SslBundle` and using it to create an `SSLContext`:
+The following example shows retrieving an javadoc:org.springframework.boot.ssl.SslBundle[] and using it to create an javadoc:javax.net.ssl.SSLContext[]:
include-code::MyComponent[]
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/task-execution-and-scheduling.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/task-execution-and-scheduling.adoc
index 1acc798476..eaceb6d0d4 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/task-execution-and-scheduling.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/features/task-execution-and-scheduling.adoc
@@ -1,26 +1,26 @@
[[features.task-execution-and-scheduling]]
= Task Execution and Scheduling
-In the absence of an `Executor` bean in the context, Spring Boot auto-configures an `AsyncTaskExecutor`.
-When virtual threads are enabled (using Java 21+ and configprop:spring.threads.virtual.enabled[] set to `true`) this will be a `SimpleAsyncTaskExecutor` that uses virtual threads.
-Otherwise, it will be a `ThreadPoolTaskExecutor` with sensible defaults.
+In the absence of an javadoc:java.util.concurrent.Executor[] bean in the context, Spring Boot auto-configures an javadoc:org.springframework.core.task.AsyncTaskExecutor[].
+When virtual threads are enabled (using Java 21+ and configprop:spring.threads.virtual.enabled[] set to `true`) this will be a javadoc:org.springframework.core.task.SimpleAsyncTaskExecutor[] that uses virtual threads.
+Otherwise, it will be a javadoc:org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor[] with sensible defaults.
In either case, the auto-configured executor will be automatically used for:
- asynchronous task execution (`@EnableAsync`)
-- Spring for GraphQL's asynchronous handling of `Callable` return values from controller methods
+- Spring for GraphQL's asynchronous handling of javadoc:java.util.concurrent.Callable[] return values from controller methods
- Spring MVC's asynchronous request processing
- Spring WebFlux's blocking execution support
[TIP]
====
-If you have defined a custom `Executor` in the context, both regular task execution (that is `@EnableAsync`) and Spring for GraphQL will use it.
-However, the Spring MVC and Spring WebFlux support will only use it if it is an `AsyncTaskExecutor` implementation (named `applicationTaskExecutor`).
-Depending on your target arrangement, you could change your `Executor` into an `AsyncTaskExecutor` or define both an `AsyncTaskExecutor` and an `AsyncConfigurer` wrapping your custom `Executor`.
+If you have defined a custom javadoc:java.util.concurrent.Executor[] in the context, both regular task execution (that is javadoc:org.springframework.scheduling.annotation.EnableAsync[format=annotation]) and Spring for GraphQL will use it.
+However, the Spring MVC and Spring WebFlux support will only use it if it is an javadoc:org.springframework.core.task.AsyncTaskExecutor[] implementation (named `applicationTaskExecutor`).
+Depending on your target arrangement, you could change your javadoc:java.util.concurrent.Executor[] into an javadoc:org.springframework.core.task.AsyncTaskExecutor[] or define both an javadoc:org.springframework.core.task.AsyncTaskExecutor[] and an javadoc:org.springframework.scheduling.annotation.AsyncConfigurer[] wrapping your custom javadoc:java.util.concurrent.Executor[].
-The auto-configured `ThreadPoolTaskExecutorBuilder` allows you to easily create instances that reproduce what the auto-configuration does by default.
+The auto-configured javadoc:org.springframework.boot.task.ThreadPoolTaskExecutorBuilder[] allows you to easily create instances that reproduce what the auto-configuration does by default.
====
-When a `ThreadPoolTaskExecutor` is auto-configured, the thread pool uses 8 core threads that can grow and shrink according to the load.
+When a javadoc:org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor[] is auto-configured, the thread pool uses 8 core threads that can grow and shrink according to the load.
Those default settings can be fine-tuned using the `spring.task.execution` namespace, as shown in the following example:
[configprops,yaml]
@@ -37,13 +37,13 @@ spring:
This changes the thread pool to use a bounded queue so that when the queue is full (100 tasks), the thread pool increases to maximum 16 threads.
Shrinking of the pool is more aggressive as threads are reclaimed when they are idle for 10 seconds (rather than 60 seconds by default).
-A scheduler can also be auto-configured if it needs to be associated with scheduled task execution (using `@EnableScheduling` for instance).
+A scheduler can also be auto-configured if it needs to be associated with scheduled task execution (using javadoc:org.springframework.scheduling.annotation.EnableScheduling[format=annotation] for instance).
-If virtual threads are enabled (using Java 21+ and configprop:spring.threads.virtual.enabled[] set to `true`) this will be a `SimpleAsyncTaskScheduler` that uses virtual threads.
-This `SimpleAsyncTaskScheduler` will ignore any pooling related properties.
+If virtual threads are enabled (using Java 21+ and configprop:spring.threads.virtual.enabled[] set to `true`) this will be a javadoc:org.springframework.scheduling.concurrent.SimpleAsyncTaskScheduler[] that uses virtual threads.
+This javadoc:org.springframework.scheduling.concurrent.SimpleAsyncTaskScheduler[] will ignore any pooling related properties.
-If virtual threads are not enabled, it will be a `ThreadPoolTaskScheduler` with sensible defaults.
-The `ThreadPoolTaskScheduler` uses one thread by default and its settings can be fine-tuned using the `spring.task.scheduling` namespace, as shown in the following example:
+If virtual threads are not enabled, it will be a javadoc:org.springframework.scheduling.concurrent.ThreadPoolTaskScheduler[] with sensible defaults.
+The javadoc:org.springframework.scheduling.concurrent.ThreadPoolTaskScheduler[] uses one thread by default and its settings can be fine-tuned using the `spring.task.scheduling` namespace, as shown in the following example:
[configprops,yaml]
----
@@ -55,5 +55,5 @@ spring:
size: 2
----
-A `ThreadPoolTaskExecutorBuilder` bean, a `SimpleAsyncTaskExecutorBuilder` bean, a `ThreadPoolTaskSchedulerBuilder` bean and a `SimpleAsyncTaskSchedulerBuilder` are made available in the context if a custom executor or scheduler needs to be created.
-The `SimpleAsyncTaskExecutorBuilder` and `SimpleAsyncTaskSchedulerBuilder` beans are auto-configured to use virtual threads if they are enabled (using Java 21+ and configprop:spring.threads.virtual.enabled[] set to `true`).
+A javadoc:org.springframework.boot.task.ThreadPoolTaskExecutorBuilder[] bean, a javadoc:org.springframework.boot.task.SimpleAsyncTaskExecutorBuilder[] bean, a javadoc:org.springframework.boot.task.ThreadPoolTaskSchedulerBuilder[] bean and a javadoc:org.springframework.boot.task.SimpleAsyncTaskSchedulerBuilder[] are made available in the context if a custom executor or scheduler needs to be created.
+The javadoc:org.springframework.boot.task.SimpleAsyncTaskExecutorBuilder[] and javadoc:org.springframework.boot.task.SimpleAsyncTaskSchedulerBuilder[] beans are auto-configured to use virtual threads if they are enabled (using Java 21+ and configprop:spring.threads.virtual.enabled[] set to `true`).
diff --git a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/io/caching.adoc b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/io/caching.adoc
index 103b62f11c..47e7a5e6c4 100644
--- a/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/io/caching.adoc
+++ b/spring-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/io/caching.adoc
@@ -4,7 +4,7 @@
The Spring Framework provides support for transparently adding caching to an application.
At its core, the abstraction applies caching to methods, thus reducing the number of executions based on the information available in the cache.
The caching logic is applied transparently, without any interference to the invoker.
-Spring Boot auto-configures the cache infrastructure as long as caching support is enabled by using the `@EnableCaching` annotation.
+Spring Boot auto-configures the cache infrastructure as long as caching support is enabled by using the javadoc:org.springframework.cache.annotation.EnableCaching[format=annotation] annotation.
NOTE: Check the {url-spring-framework-docs}/integration/cache.html[relevant section] of the Spring Framework reference for more details.
@@ -17,7 +17,7 @@ Before invoking `computePiDecimal`, the abstraction looks for an entry in the `p
If an entry is found, the content in the cache is immediately returned to the caller, and the method is not invoked.
Otherwise, the method is invoked, and the cache is updated before returning the value.
-CAUTION: You can also use the standard JSR-107 (JCache) annotations (such as `@CacheResult`) transparently.
+CAUTION: You can also use the standard JSR-107 (JCache) annotations (such as javadoc:javax.cache.annotation.CacheResult[format=annotation]) transparently.
However, we strongly advise you to not mix and match the Spring Cache and JCache annotations.
If you do not add any specific cache library, Spring Boot auto-configures a xref:io/caching.adoc#io.caching.provider.simple[simple provider] that uses concurrent maps in memory.
@@ -34,9 +34,9 @@ TIP: It is also possible to transparently {url-spring-framework-docs}/integratio
[[io.caching.provider]]
== Supported Cache Providers
-The cache abstraction does not provide an actual store and relies on abstraction materialized by the `org.springframework.cache.Cache` and `org.springframework.cache.CacheManager` interfaces.
+The cache abstraction does not provide an actual store and relies on abstraction materialized by the javadoc:org.springframework.cache.Cache[] and javadoc:org.springframework.cache.CacheManager[] interfaces.
-If you have not defined a bean of type `CacheManager` or a `CacheResolver` named `cacheResolver` (see javadoc:{url-spring-framework-javadoc}/org.springframework.cache.annotation.CachingConfigurer[]), Spring Boot tries to detect the following providers (in the indicated order):
+If you have not defined a bean of type javadoc:org.springframework.cache.CacheManager[] or a javadoc:org.springframework.cache.interceptor.CacheResolver[] named `cacheResolver` (see javadoc:{url-spring-framework-javadoc}/org.springframework.cache.annotation.CachingConfigurer[]), Spring Boot tries to detect the following providers (in the indicated order):
. xref:io/caching.adoc#io.caching.provider.generic[]
. xref:io/caching.adoc#io.caching.provider.jcache[] (EhCache 3, Hazelcast, Infinispan, and others)
@@ -50,36 +50,36 @@ If you have not defined a bean of type `CacheManager` or a `CacheResolver` named
Additionally, {url-spring-boot-for-apache-geode-site}[Spring Boot for Apache Geode] provides {url-spring-boot-for-apache-geode-docs}#geode-caching-provider[auto-configuration for using Apache Geode as a cache provider].
-TIP: If the `CacheManager` is auto-configured by Spring Boot, it is possible to _force_ a particular cache provider by setting the configprop:spring.cache.type[] property.
+TIP: If the javadoc:org.springframework.cache.CacheManager[] is auto-configured by Spring Boot, it is possible to _force_ a particular cache provider by setting the configprop:spring.cache.type[] property.
Use this property if you need to xref:io/caching.adoc#io.caching.provider.none[use no-op caches] in certain environments (such as tests).
TIP: Use the `spring-boot-starter-cache` starter to quickly add basic caching dependencies.
The starter brings in `spring-context-support`.
If you add dependencies manually, you must include `spring-context-support` in order to use the JCache or Caffeine support.
-If the `CacheManager` is auto-configured by Spring Boot, you can further tune its configuration before it is fully initialized by exposing a bean that implements the `CacheManagerCustomizer` interface.
+If the javadoc:org.springframework.cache.CacheManager[] is auto-configured by Spring Boot, you can further tune its configuration before it is fully initialized by exposing a bean that implements the javadoc:org.springframework.boot.autoconfigure.cache.CacheManagerCustomizer[] interface.
The following example sets a flag to say that `null` values should not be passed down to the underlying map:
include-code::MyCacheManagerConfiguration[]
-NOTE: In the preceding example, an auto-configured `ConcurrentMapCacheManager` is expected.
+NOTE: In the preceding example, an auto-configured javadoc:org.springframework.cache.concurrent.ConcurrentMapCacheManager[] is expected.
If that is not the case (either you provided your own config or a different cache provider was auto-configured), the customizer is not invoked at all.
-You can have as many customizers as you want, and you can also order them by using `@Order` or `Ordered`.
+You can have as many customizers as you want, and you can also order them by using javadoc:org.springframework.core.annotation.Order[format=annotation] or javadoc:org.springframework.core.Ordered[].
[[io.caching.provider.generic]]
=== Generic
-Generic caching is used if the context defines _at least_ one `org.springframework.cache.Cache` bean.
-A `CacheManager` wrapping all beans of that type is created.
+Generic caching is used if the context defines _at least_ one javadoc:org.springframework.cache.Cache[] bean.
+A javadoc:org.springframework.cache.CacheManager[] wrapping all beans of that type is created.
[[io.caching.provider.jcache]]
=== JCache (JSR-107)
-https://jcp.org/en/jsr/detail?id=107[JCache] is bootstrapped through the presence of a `javax.cache.spi.CachingProvider` on the classpath (that is, a JSR-107 compliant caching library exists on the classpath), and the `JCacheCacheManager` is provided by the `spring-boot-starter-cache` starter.
+https://jcp.org/en/jsr/detail?id=107[JCache] is bootstrapped through the presence of a javadoc:javax.cache.spi.CachingProvider[] on the classpath (that is, a JSR-107 compliant caching library exists on the classpath), and the javadoc:org.springframework.cache.jcache.JCacheCacheManager[] is provided by the `spring-boot-starter-cache` starter.
Various compliant libraries are available, and Spring Boot provides dependency management for Ehcache 3, Hazelcast, and Infinispan.
Any other compliant library can be added as well.
@@ -99,15 +99,15 @@ Even if the JSR-107 standard does not enforce a standardized way to define the l
NOTE: When a cache library offers both a native implementation and JSR-107 support, Spring Boot prefers the JSR-107 support, so that the same features are available if you switch to a different JSR-107 implementation.
TIP: Spring Boot has xref:io/hazelcast.adoc[general support for Hazelcast].
-If a single `HazelcastInstance` is available, it is automatically reused for the `CacheManager` as well, unless the configprop:spring.cache.jcache.config[] property is specified.
+If a single javadoc:com.hazelcast.core.HazelcastInstance[] is available, it is automatically reused for the javadoc:javax.cache.CacheManager[] as well, unless the configprop:spring.cache.jcache.config[] property is specified.
-There are two ways to customize the underlying `javax.cache.CacheManager`:
+There are two ways to customize the underlying javadoc:javax.cache.CacheManager[]:
* Caches can be created on startup by setting the configprop:spring.cache.cache-names[] property.
-If a custom `javax.cache.configuration.Configuration` bean is defined, it is used to customize them.
-* `org.springframework.boot.autoconfigure.cache.JCacheManagerCustomizer` beans are invoked with the reference of the `CacheManager` for full customization.
+If a custom javadoc:javax.cache.configuration.Configuration[] bean is defined, it is used to customize them.
+* javadoc:org.springframework.boot.autoconfigure.cache.JCacheManagerCustomizer[] beans are invoked with the reference of the javadoc:javax.cache.CacheManager[] for full customization.
-TIP: If a standard `javax.cache.CacheManager` bean is defined, it is wrapped automatically in an `org.springframework.cache.CacheManager` implementation that the abstraction expects.
+TIP: If a standard javadoc:javax.cache.CacheManager[] bean is defined, it is wrapped automatically in an javadoc:org.springframework.cache.CacheManager[] implementation that the abstraction expects.
No further customization is applied to it.
@@ -116,10 +116,10 @@ No further customization is applied to it.
=== Hazelcast
Spring Boot has xref:io/hazelcast.adoc[general support for Hazelcast].
-If a `HazelcastInstance` has been auto-configured and `com.hazelcast:hazelcast-spring` is on the classpath, it is automatically wrapped in a `CacheManager`.
+If a javadoc:com.hazelcast.core.HazelcastInstance[] has been auto-configured and `com.hazelcast:hazelcast-spring` is on the classpath, it is automatically wrapped in a javadoc:org.springframework.cache.CacheManager[].
-NOTE: Hazelcast can be used as a JCache compliant cache or as a Spring `CacheManager` compliant cache.
-When setting configprop:spring.cache.type[] to `hazelcast`, Spring Boot will use the `CacheManager` based implementation.
+NOTE: Hazelcast can be used as a JCache compliant cache or as a Spring javadoc:org.springframework.cache.CacheManager[] compliant cache.
+When setting configprop:spring.cache.type[] to `hazelcast`, Spring Boot will use the javadoc:org.springframework.cache.CacheManager[] based implementation.
If you want to use Hazelcast as a JCache compliant cache, set configprop:spring.cache.type[] to `jcache`.
If you have multiple JCache compliant cache providers and want to force the use of Hazelcast, you have to xref:io/caching.adoc#io.caching.provider.jcache[explicitly set the JCache provider].
@@ -140,7 +140,7 @@ spring:
----
Caches can be created on startup by setting the configprop:spring.cache.cache-names[] property.
-If a custom `ConfigurationBuilder` bean is defined, it is used to customize the caches.
+If a custom javadoc:org.infinispan.configuration.cache.ConfigurationBuilder[] bean is defined, it is used to customize the caches.
To be compatible with Spring Boot's Jakarta EE 9 baseline, Infinispan's `-jakarta` modules must be used.
For every module with a `-jakarta` variant, the variant must be used in place of the standard module.
@@ -151,7 +151,7 @@ For example, `infinispan-core-jakarta` and `infinispan-commons-jakarta` must be
[[io.caching.provider.couchbase]]
=== Couchbase
-If Spring Data Couchbase is available and Couchbase is xref:data/nosql.adoc#data.nosql.couchbase[configured], a `CouchbaseCacheManager` is auto-configured.
+If Spring Data Couchbase is available and Couchbase is xref:data/nosql.adoc#data.nosql.couchbase[configured], a javadoc:org.springframework.data.couchbase.cache.CouchbaseCacheManager[] is auto-configured.
It is possible to create additional caches on startup by setting the configprop:spring.cache.cache-names[] property and cache defaults can be configured by using `spring.cache.couchbase.*` properties.
For instance, the following configuration creates `cache1` and `cache2` caches with an entry _expiration_ of 10 minutes:
@@ -164,7 +164,7 @@ spring:
expiration: "10m"
----
-If you need more control over the configuration, consider registering a `CouchbaseCacheManagerBuilderCustomizer` bean.
+If you need more control over the configuration, consider registering a javadoc:org.springframework.boot.autoconfigure.cache.CouchbaseCacheManagerBuilderCustomizer[] bean.
The following example shows a customizer that configures a specific entry expiration for `cache1` and `cache2`:
include-code::MyCouchbaseCacheManagerConfiguration[]
@@ -174,7 +174,7 @@ include-code::MyCouchbaseCacheManagerConfiguration[]
[[io.caching.provider.redis]]
=== Redis
-If https://redis.io/[Redis] is available and configured, a `RedisCacheManager` is auto-configured.
+If https://redis.io/[Redis] is available and configured, a javadoc:org.springframework.data.redis.cache.RedisCacheManager[] is auto-configured.
It is possible to create additional caches on startup by setting the configprop:spring.cache.cache-names[] property and cache defaults can be configured by using `spring.cache.redis.*` properties.
For instance, the following configuration creates `cache1` and `cache2` caches with a _time to live_ of 10 minutes:
@@ -188,12 +188,12 @@ spring:
----
NOTE: By default, a key prefix is added so that, if two separate caches use the same key, Redis does not have overlapping keys and cannot return invalid values.
-We strongly recommend keeping this setting enabled if you create your own `RedisCacheManager`.
+We strongly recommend keeping this setting enabled if you create your own javadoc:org.springframework.data.redis.cache.RedisCacheManager[].
-TIP: You can take full control of the default configuration by adding a `RedisCacheConfiguration` `@Bean` of your own.
+TIP: You can take full control of the default configuration by adding a javadoc:org.springframework.data.redis.cache.RedisCacheConfiguration[] javadoc:org.springframework.context.annotation.Bean[format=annotation] of your own.
This can be useful if you need to customize the default serialization strategy.
-If you need more control over the configuration, consider registering a `RedisCacheManagerBuilderCustomizer` bean.
+If you need more control over the configuration, consider registering a javadoc:org.springframework.boot.autoconfigure.cache.RedisCacheManagerBuilderCustomizer[] bean.
The following example shows a customizer that configures a specific time to live for `cache1` and `cache2`:
include-code::MyRedisCacheManagerConfiguration[]
@@ -204,12 +204,12 @@ include-code::MyRedisCacheManagerConfiguration[]
=== Caffeine
https://github.com/ben-manes/caffeine[Caffeine] is a Java 8 rewrite of Guava's cache that supersedes support for Guava.
-If Caffeine is present, a `CaffeineCacheManager` (provided by the `spring-boot-starter-cache` starter) is auto-configured.
+If Caffeine is present, a javadoc:org.springframework.cache.caffeine.CaffeineCacheManager[] (provided by the `spring-boot-starter-cache` starter) is auto-configured.
Caches can be created on startup by setting the configprop:spring.cache.cache-names[] property and can be customized by one of the following (in the indicated order):
. A cache spec defined by `spring.cache.caffeine.spec`
-. A `com.github.benmanes.caffeine.cache.CaffeineSpec` bean is defined
-. A `com.github.benmanes.caffeine.cache.Caffeine` bean is defined
+. A javadoc:com.github.benmanes.caffeine.cache.CaffeineSpec[] bean is defined
+. A javadoc:com.github.benmanes.caffeine.cache.Caffeine[] bean is defined
For instance, the following configuration creates `cache1` and `cache2` caches with a maximum size of 500 and a _time to live_ of 10 minutes
@@ -222,8 +222,8 @@ spring:
spec: "maximumSize=500,expireAfterAccess=600s"
----
-If a `com.github.benmanes.caffeine.cache.CacheLoader` bean is defined, it is automatically associated to the `CaffeineCacheManager`.
-Since the `CacheLoader` is going to be associated with _all_ caches managed by the cache manager, it must be defined as `CacheLoader