Migrate class references to full javadoc links

Update documentation to use `javadoc:...` macro for class and interface
references.

Migrated using https://github.com/philwebb/asciidoctor-javadoc-migration

See gh-41614

Author: philwebb

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:
 </dependency>
 ----
 
-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.
 

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[].
 

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 `org.springframework.core.env.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 `org.springframework.boot.actuate.health.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:
 

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,58 +46,58 @@ 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]
 ----
 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.
 
 
 
 [[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.