Polish documentation to use more javadoc links
Update a few areas of the documentation to use full javadoc links. See gh-41614
This commit is contained in:
Phillip Webb
@@ -25,7 +25,7 @@ Various settings can also be configured on the repackager before it is run.
|
||||
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.
|
||||
|
||||
If your archive already includes libraries, you can use `Libraries.NONE`.
|
||||
If your archive already includes libraries, you can use javadoc:org.springframework.boot.loader.tools.Libraries#NONE[].
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -441,7 +441,7 @@ server:
|
||||
filename: "/var/log/jetty-access.log"
|
||||
----
|
||||
|
||||
By default, logs are redirected to `System.err`.
|
||||
By default, logs are redirected to javadoc:java.lang.System#err[].
|
||||
For more details, see the Jetty documentation.
|
||||
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ Spring Boot uses a very particular `PropertySource` order that is designed to al
|
||||
Later property sources can override the values defined in earlier ones.
|
||||
Sources are considered in the following order:
|
||||
|
||||
. Default properties (specified by setting `SpringApplication.setDefaultProperties`).
|
||||
. 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.
|
||||
This is too late to configure certain properties such as `+logging.*+` and `+spring.main.*+` which are read before refresh begins.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
= SpringApplication
|
||||
|
||||
The `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 `SpringApplication.run` method, as shown in the following example:
|
||||
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[]
|
||||
|
||||
@@ -127,7 +127,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.
|
||||
|
||||
You can also use the configprop:spring.main.banner-mode[] property to determine if the banner has to be printed on `System.out` (`console`), sent to the configured logger (`log`), or not produced at all (`off`).
|
||||
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`).
|
||||
|
||||
The printed banner is registered as a singleton bean under the following name: `springBootBanner`.
|
||||
|
||||
@@ -260,9 +260,9 @@ Application events are sent in the following order, as your application runs:
|
||||
. 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 `LivenessState.CORRECT` to indicate that the application is considered as live.
|
||||
. 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 `ReadinessState.ACCEPTING_TRAFFIC` to indicate that the application is ready to service requests.
|
||||
. 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.
|
||||
|
||||
The above list only includes ``SpringApplicationEvent``s that are tied to a `SpringApplication`.
|
||||
|
||||
@@ -36,7 +36,7 @@ The required dependencies are provided by the `spring-boot-starter-rsocket`.
|
||||
Spring Boot allows exposing RSocket over WebSocket from a WebFlux server, or standing up an independent RSocket server.
|
||||
This depends on the type of application and its configuration.
|
||||
|
||||
For WebFlux application (that is of type `WebApplicationType.REACTIVE`), the RSocket server will be plugged into the Web Server only if the following properties match:
|
||||
For WebFlux application (that is of type javadoc:org.springframework.boot.WebApplicationType#REACTIVE[]), the RSocket server will be plugged into the Web Server only if the following properties match:
|
||||
|
||||
[configprops,yaml]
|
||||
----
|
||||
|
||||
@@ -85,8 +85,8 @@ For example, the following is a very common code pattern for a typical Spring Bo
|
||||
|
||||
include-code::typical/MyApplication[]
|
||||
|
||||
In the example above, the `main` method doesn't do anything other than delegate to `SpringApplication.run`.
|
||||
It is, however, possible to have a more complex `main` method that applies customizations before calling `SpringApplication.run`.
|
||||
In the example above, the `main` method doesn't do anything other than delegate to javadoc:org.springframework.boot.SpringApplication#run(java.lang.Class,java.lang.String...)[].
|
||||
It is, however, possible to have a more complex `main` method that applies customizations before calling javadoc:org.springframework.boot.SpringApplication#run(java.lang.Class,java.lang.String...)[].
|
||||
|
||||
For example, here is an application that changes the banner mode and sets additional profiles:
|
||||
|
||||
@@ -95,7 +95,7 @@ include-code::custom/MyApplication[]
|
||||
Since customizations in the `main` method can affect the resulting `ApplicationContext`, it's possible that you might also want to use the `main` method to create the `ApplicationContext` used in your tests.
|
||||
By default, `@SpringBootTest` will not call your `main` method, and instead the class itself is used directly to create the `ApplicationContext`
|
||||
|
||||
If you want to change this behavior, you can change the `useMainMethod` attribute of `@SpringBootTest` to `UseMainMethod.ALWAYS` or `UseMainMethod.WHEN_AVAILABLE`.
|
||||
If you want to change this behavior, you can change the `useMainMethod` attribute of `@SpringBootTest` to javadoc:org.springframework.boot.test.context.SpringBootTest$UseMainMethod#ALWAYS[] or javadoc:org.springframework.boot.test.context.SpringBootTest$UseMainMethod#WHEN_AVAILABLE[].
|
||||
When set to `ALWAYS`, the test will fail if no `main` method can be found.
|
||||
When set to `WHEN_AVAILABLE` the `main` method will be used if it is available, otherwise the standard loading mechanism will be used.
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ include-code::MyEnvironmentTests[]
|
||||
[[testing.utilities.output-capture]]
|
||||
== OutputCaptureExtension
|
||||
|
||||
`OutputCaptureExtension` is a JUnit `Extension` that you can use to capture `System.out` and `System.err` output.
|
||||
`OutputCaptureExtension` is a JUnit `Extension` that you can use to capture javadoc:java.lang.System#out[] and javadoc:java.lang.System#err[] output.
|
||||
To use it, add `@ExtendWith(OutputCaptureExtension.class)` and inject `CapturedOutput` as an argument to your test class constructor or test method as follows:
|
||||
|
||||
include-code::MyOutputCaptureTests[]
|
||||
|
||||
@@ -81,7 +81,7 @@ The following service connection factories are provided in the `spring-boot-test
|
||||
| Containers of type `PulsarContainer`
|
||||
|
||||
| `R2dbcConnectionDetails`
|
||||
| Containers of type `MariaDBContainer`, `MSSQLServerContainer`, `MySQLContainer`, `OracleContainer`, or `PostgreSQLContainer`
|
||||
| Containers of type `MariaDBContainer`, `MSSQLServerContainer`, `MySQLContainer`, javadoc:{url-testcontainers-oracle-free-javadoc}/org.testcontainers.OracleContainer[OracleContainer (free)], javadoc:{url-testcontainers-oracle-xe-javadoc}/org.testcontainers.oracle.OracleContainer[OracleContainer (XE)] or `PostgreSQLContainer`
|
||||
|
||||
| `RabbitConnectionDetails`
|
||||
| Containers of type `RabbitMQContainer`
|
||||
|
||||
@@ -7,7 +7,7 @@ You need to consider the following restrictions when working with a Spring Boot
|
||||
|
||||
[[appendix.executable-jar-zip-entry-compression]]
|
||||
* Zip entry compression:
|
||||
The `ZipEntry` for a nested jar must be saved by using the `ZipEntry.STORED` method.
|
||||
The `ZipEntry` for a nested jar must be saved by using the javadoc:java.util.zip.ZipEntry#STORED[] method.
|
||||
This is required so that we can seek directly to individual content within the nested jar.
|
||||
The content of the nested jar file itself can still be compressed, as can any other entry in the outer jar.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user