mirror of
https://github.com/spring-projects/spring-boot.git
synced 2024-07-05 00:56:58 +08:00
Merge branch '3.3.x'
This commit is contained in:
Scott Frederick
commit
17c5538062
@ -1,5 +1,5 @@
|
||||
[[integrationgraph]]
|
||||
= Spring Integration graph (`integrationgraph`)
|
||||
= Spring Integration Graph (`integrationgraph`)
|
||||
|
||||
The `integrationgraph` endpoint exposes a graph containing all Spring Integration components.
|
||||
|
||||
|
||||
@ -55,7 +55,7 @@ include::partial$rest/actuator/metrics/metric-with-tags/query-parameters.adoc[]
|
||||
|
||||
|
||||
[[metrics.retrieving-metric.response-structure]]
|
||||
=== Response structure
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the metric.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
@ -6,7 +6,7 @@ The `sbom` endpoint provides information about the software bill of materials (S
|
||||
|
||||
|
||||
[[sbom.retrieving-available-sboms]]
|
||||
== Retrieving the available SBOMs
|
||||
== Retrieving the Available SBOMs
|
||||
|
||||
To retrieve the available SBOMs, make a `GET` request to `/actuator/sbom`, as shown in the following curl-based example:
|
||||
|
||||
@ -30,7 +30,7 @@ include::partial$rest/actuator/sbom/response-fields.adoc[]
|
||||
|
||||
|
||||
[[sbom.retrieving-single-sbom]]
|
||||
== Retrieving a single SBOM
|
||||
== Retrieving a Single SBOM
|
||||
|
||||
To retrieve the available SBOMs, make a `GET` request to `/actuator/sbom/\{id}`, as shown in the following curl-based example:
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
[[howto.aot]]
|
||||
= Ahead-of-time processing
|
||||
= Ahead-of-Time Processing
|
||||
|
||||
A number of questions often arise when people use the ahead-of-time processing of Spring Boot applications.
|
||||
This section addresses those questions.
|
||||
|
||||
@ -68,7 +68,7 @@ This provides only one argument to the batch job: `someParameter=someValue`.
|
||||
|
||||
|
||||
[[howto.batch.restarting-a-failed-job]]
|
||||
== Restarting a stopped or 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.
|
||||
Non-identifying parameters are *not* copied from the previous execution.
|
||||
|
||||
@ -18,7 +18,7 @@ The buildpack environment variable `BP_SPRING_AOT_ENABLED` can also be set to `t
|
||||
The Paketo Buildpack for Spring Boot https://github.com/paketo-buildpacks/spring-boot?tab=readme-ov-file#configuration[documentation] has information on other configuration options that can be enabled with builder environment variables, like `CDS_TRAINING_JAVA_TOOL_OPTIONS` that allows to override the default `JAVA_TOOL_OPTIONS`, only for the CDS training run.
|
||||
|
||||
[[howto.class-data-sharing.training-run-configuration]]
|
||||
== Preventing remote services interaction during the training run
|
||||
== Preventing Remote Services Interaction During the Training Run
|
||||
|
||||
When performing the training run, it may be needed to customize the Spring Boot application configuration to prevent connections to remote services that may happen before the Spring lifecycle is started.
|
||||
This can typically happen with early database interactions and can be handled via related configuration that can be applied by default to your application (or specifically to the training run) to prevent such interactions, see https://github.com/spring-projects/spring-lifecycle-smoke-tests/blob/main/README.adoc#training-run-configuration[related documentation].
|
||||
|
||||
@ -192,7 +192,7 @@ You can also use a `Customizer<Liquibase>` bean if you want to customize the `Li
|
||||
|
||||
|
||||
[[howto.data-initialization.migration-tool.flyway-tests]]
|
||||
=== Use Flyway for test-only migrations
|
||||
=== Use Flyway for Test-only Migrations
|
||||
|
||||
If you want to create Flyway migrations which populate your test database, place them in `src/test/resources/db/migration`.
|
||||
A file named, for example, `src/test/resources/db/migration/V9999__test-data.sql` will be executed after your production migrations and only if you're running the tests.
|
||||
@ -202,7 +202,7 @@ This file will not be packaged in your uber jar or your container.
|
||||
|
||||
|
||||
[[howto.data-initialization.migration-tool.liquibase-tests]]
|
||||
=== Use Liquibase for test-only migrations
|
||||
=== Use Liquibase for Test-only Migrations
|
||||
|
||||
If you want to create Liquibase migrations which populate your test database, you have to create a test changelog which also includes the production changelog.
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ With this Docker Compose file in place, the JDBC URL used is `jdbc:postgresql://
|
||||
|
||||
|
||||
[[howto.docker-compose.sharing-services]]
|
||||
== Sharing services between multiple applications
|
||||
== Sharing Services Between Multiple Applications
|
||||
|
||||
If you want to share services between multiple applications, create the `compose.yaml` file in one of the applications and then use the configuration property configprop:spring.docker.compose.file[] in the other applications to reference the `compose.yaml` file.
|
||||
You should also set configprop:spring.docker.compose.lifecycle-management[] to `start-only`, as it defaults to `start-and-stop` and stopping one application would shut down the shared services for the other still running applications as well.
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
|
||||
[[howto.jersey.spring-security]]
|
||||
== Secure Jersey endpoints with Spring Security
|
||||
== Secure Jersey Endpoints with Spring Security
|
||||
|
||||
Spring Security can be used to secure a Jersey-based web application in much the same way as it can be used to secure a Spring MVC-based web application.
|
||||
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)`.
|
||||
|
||||
@ -14,7 +14,7 @@ For native image testing, you're generally looking to ensure that the following
|
||||
|
||||
|
||||
[[howto.native-image.testing.with-the-jvm]]
|
||||
== Testing Ahead-of-time Processing With the JVM
|
||||
== Testing Ahead-of-Time Processing With the JVM
|
||||
|
||||
When a Spring Boot application runs, it attempts to detect if it is running as a native image.
|
||||
If it is running as a native image, it will initialize the application using the code that was generated during at build-time by the Spring AOT engine.
|
||||
|
||||
@ -8,7 +8,7 @@ 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
|
||||
== 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.
|
||||
|
||||
@ -25,7 +25,7 @@ The easiest way to add user accounts is by providing your own `UserDetailsServic
|
||||
|
||||
|
||||
[[howto.security.enable-https]]
|
||||
== Enable HTTPS When Running behind a Proxy Server
|
||||
== 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).
|
||||
|
||||
@ -184,7 +184,7 @@ Configuring the `DispatcherServlet` yourself is unusual but if you really need t
|
||||
|
||||
|
||||
[[howto.spring-mvc.switch-off-default-configuration]]
|
||||
== Switch off the Default MVC 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.
|
||||
Doing so leaves all MVC configuration in your hands.
|
||||
|
||||
@ -22,7 +22,7 @@ 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 `@Configuration` 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.
|
||||
|
||||
@ -28,7 +28,7 @@ TIP: To learn more about Micrometer's capabilities, see its {url-micrometer-docs
|
||||
|
||||
|
||||
[[actuator.metrics.getting-started]]
|
||||
== 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.
|
||||
Having a dependency on `micrometer-registry-\{system}` in your runtime classpath is enough for Spring Boot to configure the registry.
|
||||
@ -206,7 +206,7 @@ This is the default behavior and requires no special setup beyond a dependency o
|
||||
|
||||
|
||||
[[actuator.metrics.export.dynatrace.v2-api.manual-config]]
|
||||
===== Manual configuration
|
||||
===== Manual Configuration
|
||||
|
||||
If no auto-configuration is available, the endpoint of the {url-dynatrace-docs-shortlink}/api-metrics-v2-post-datapoints[Metrics v2 API] and an API token are required.
|
||||
The {url-dynatrace-docs-shortlink}/api-authentication[API token] must have the "`Ingest metrics`" (`metrics.ingest`) permission set.
|
||||
|
||||
@ -30,7 +30,7 @@ To enable it, add the `io.r2dbc:r2dbc-proxy` dependency to your project.
|
||||
|
||||
|
||||
[[actuator.observability.common-tags]]
|
||||
== Common tags
|
||||
== Common Tags
|
||||
|
||||
Common tags are generally used for dimensional drill-down on the operating environment, such as host, instance, region, stack, and others.
|
||||
Common tags are applied to all observations as low cardinality tags and can be configured, as the following example shows:
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
[[features.dev-services]]
|
||||
= Development-time services
|
||||
= Development-time Services
|
||||
|
||||
Development-time services provide external dependencies needed to run the application while developing it.
|
||||
They are only supposed to be used while developing and are disabled when the application is deployed.
|
||||
|
||||
@ -98,7 +98,7 @@ Among other things, the extensions make it possible to take advantage of Kotlin
|
||||
|
||||
|
||||
[[features.kotlin.dependency-management]]
|
||||
== Dependency management
|
||||
== Dependency Management
|
||||
|
||||
In order to avoid mixing different versions of Kotlin dependencies on the classpath, Spring Boot imports the Kotlin BOM.
|
||||
|
||||
@ -155,7 +155,7 @@ If you need the `MockK` equivalent of the Mockito specific xref:testing/spring-b
|
||||
|
||||
|
||||
[[features.kotlin.resources.further-reading]]
|
||||
=== Further reading
|
||||
=== Further Reading
|
||||
|
||||
* {url-kotlin-docs}[Kotlin language reference]
|
||||
* https://kotlinlang.slack.com/[Kotlin Slack] (with a dedicated #spring channel)
|
||||
|
||||
@ -28,7 +28,7 @@ Note that their `@Order` is important, as it determines the order of codecs.
|
||||
|
||||
|
||||
[[messaging.rsocket.server-auto-configuration]]
|
||||
== RSocket server Auto-configuration
|
||||
== RSocket Server Auto-configuration
|
||||
|
||||
Spring Boot provides RSocket server auto-configuration.
|
||||
The required dependencies are provided by the `spring-boot-starter-rsocket`.
|
||||
@ -63,7 +63,7 @@ spring:
|
||||
|
||||
|
||||
[[messaging.rsocket.messaging]]
|
||||
== Spring Messaging RSocket support
|
||||
== Spring Messaging RSocket Support
|
||||
|
||||
Spring Boot will auto-configure the Spring Messaging infrastructure for RSocket.
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
[[packaging.aot]]
|
||||
= Ahead-of-time Processing With the JVM
|
||||
= Ahead-of-Time Processing With the JVM
|
||||
|
||||
It's beneficial for the startup time to run your application using the AOT generated initialization code.
|
||||
First, you need to ensure that the jar you are building includes AOT generated code.
|
||||
|
||||
@ -171,7 +171,7 @@ But when you work with `WebClient`, `RestClient` or `RestTemplate` directly, you
|
||||
|
||||
|
||||
[[packaging.native-image.advanced.custom-hints.testing]]
|
||||
=== Testing custom hints
|
||||
=== Testing Custom Hints
|
||||
|
||||
The `RuntimeHintsPredicates` API can be used to test your hints.
|
||||
The API provides methods that build a `Predicate` that can be used to test a `RuntimeHints` instance.
|
||||
|
||||
@ -153,7 +153,7 @@ Spring Boot will automatically detect `DataFetcherExceptionResolver` beans and r
|
||||
|
||||
|
||||
[[web.graphql.graphiql]]
|
||||
== GraphiQL and Schema printer
|
||||
== GraphiQL and Schema Printer
|
||||
|
||||
Spring GraphQL offers infrastructure for helping developers when consuming or developing a GraphQL API.
|
||||
|
||||
|
||||
@ -75,7 +75,7 @@ OS: Linux 6.2.12-200.fc37.aarch64 aarch64
|
||||
|
||||
|
||||
[[getting-started.first-application.pom]]
|
||||
== Setting up the project with Maven
|
||||
== Setting Up the Project With Maven
|
||||
|
||||
We need to start by creating a Maven `pom.xml` file.
|
||||
The `pom.xml` is the recipe that is used to build your project.
|
||||
@ -136,7 +136,7 @@ For simplicity, we continue to use a plain text editor for this example.
|
||||
|
||||
|
||||
[[getting-started.first-application.gradle]]
|
||||
== Setting up the project with Gradle
|
||||
== Setting Up the Project With Gradle
|
||||
|
||||
We need to start by creating a Gradle `build.gradle` file.
|
||||
The `build.gradle` is the build script that is used to build your project.
|
||||
|
||||
@ -245,7 +245,7 @@ Applications that require a shell to run a start script, as might be the case wh
|
||||
|
||||
|
||||
[[build-image.customization.tags]]
|
||||
=== Tags format
|
||||
=== Tags Format
|
||||
|
||||
The values provided to the `tags` option should be *full* image references.
|
||||
The accepted format is `[domainHost:port/][path/]name[:tag][@digest]`.
|
||||
|
||||
@ -90,7 +90,7 @@ include::example$running/application-plugin-main-class-name.gradle.kts[tags=main
|
||||
|
||||
|
||||
[[running-your-application.passing-arguments]]
|
||||
== Passing Arguments to your Application
|
||||
== Passing Arguments to Your Application
|
||||
|
||||
Like all `JavaExec` tasks, arguments can be passed into `bootRun` from the command line using `--args='<arguments>'` when using Gradle 4.9 or later.
|
||||
For example, to run your application with a profile named `dev` active the following command can be used:
|
||||
@ -105,7 +105,7 @@ See {url-gradle-javadoc}/org/gradle/api/tasks/JavaExec.html#setArgsString-java.l
|
||||
|
||||
|
||||
[[running-your-application.passing-system-properties]]
|
||||
== Passing System properties to your application
|
||||
== Passing System Properties to Your application
|
||||
|
||||
Since `bootRun` is a standard `JavaExec` task, system properties can be passed to the application's JVM by specifying them in the build script.
|
||||
To make that value of a system property to be configurable set its value using a {url-gradle-dsl}/org.gradle.api.Project.html#N14FE1[project property].
|
||||
|
||||
@ -250,7 +250,7 @@ For more details, see also xref:build-image.adoc#build-image.examples[examples].
|
||||
|
||||
|
||||
[[build-image.customization.tags]]
|
||||
=== Tags format
|
||||
=== Tags Format
|
||||
|
||||
The values provided to the `tags` option should be *full* image references.
|
||||
The accepted format is `[domainHost:port/][path/]name[:tag][@digest]`.
|
||||
|
||||
@ -60,7 +60,7 @@ You can now retrieve the `test.server.port` system property in any of your integ
|
||||
|
||||
|
||||
[[integration-tests.examples.jmx-port]]
|
||||
=== Customize JMX port
|
||||
=== Customize JMX Port
|
||||
|
||||
The `jmxPort` property allows to customize the port the plugin uses to communicate with the Spring Boot application.
|
||||
|
||||
|
||||
@ -94,9 +94,9 @@ include::example$using/no-starter-parent-override-dependencies-pom.xml[tags=no-s
|
||||
|
||||
|
||||
[[using.overriding-command-line]]
|
||||
== Overriding settings on the command-line
|
||||
== Overriding Settings on the Command Line
|
||||
|
||||
The plugin offers a number of user properties, starting with `spring-boot`, to let you customize the configuration from the command-line.
|
||||
The plugin offers a number of user properties, starting with `spring-boot`, to let you customize the configuration from the command line.
|
||||
|
||||
For instance, you could tune the profiles to enable when running the application as follows:
|
||||
|
||||
@ -105,7 +105,7 @@ For instance, you could tune the profiles to enable when running the application
|
||||
$ mvn spring-boot:run -Dspring-boot.run.profiles=dev,local
|
||||
----
|
||||
|
||||
If you want to both have a default while allowing it to be overridden on the command-line, you should use a combination of a user-provided project property and MOJO configuration.
|
||||
If you want to both have a default while allowing it to be overridden on the command line, you should use a combination of a user-provided project property and MOJO configuration.
|
||||
|
||||
[source,xml,indent=0,subs="verbatim,attributes"]
|
||||
----
|
||||
@ -113,7 +113,7 @@ include::example$using/default-and-override-pom.xml[tags=default-and-override]
|
||||
----
|
||||
|
||||
The above makes sure that `local` and `dev` are enabled by default.
|
||||
Now a dedicated property has been exposed, this can be overridden on the command-line as well:
|
||||
Now a dedicated property has been exposed, this can be overridden on the command line as well:
|
||||
|
||||
[source,shell]
|
||||
----
|
||||
|
||||
Loading…
Reference in New Issue
Block a user