Build and Deploy Snapshot / Build and Deploy Snapshot (push) Waiting to runDetails
Build and Deploy Snapshot / Trigger Docs Build (push) Blocked by required conditionsDetails
Build and Deploy Snapshot / Verify (push) Blocked by required conditionsDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:17], map[id:${{ vars.UBUNTU_MEDIUM || 'ubuntu-latest' }} name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:17], map[id:windows-latest name:Windows]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:21], map[id:${{ vars.UBUNTU_MEDIUM || 'ubuntu-latest' }} name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:21], map[id:windows-latest name:Windows]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:24], map[id:${{ vars.UBUNTU_MEDIUM || 'ubuntu-latest' }} name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:24], map[id:windows-latest name:Windows]) (push) Waiting to runDetails
Run CodeQL Analysis / run-analysis (push) Waiting to runDetails
Run System Tests / Java ${{ matrix.java.version}} (map[toolchain:false version:17]) (push) Waiting to runDetails
Run System Tests / Java ${{ matrix.java.version}} (map[toolchain:true version:21]) (push) Waiting to runDetails
Rather than documenting what should be added to use Infinispan as a
cache provider, this commit adds a reference to the official
documentation.
Closes gh-48191
Build and Deploy Snapshot / Build and Deploy Snapshot (push) Waiting to runDetails
Build and Deploy Snapshot / Trigger Docs Build (push) Blocked by required conditionsDetails
Build and Deploy Snapshot / Verify (push) Blocked by required conditionsDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:25], map[id:${{ vars.UBUNTU_MEDIUM || 'ubuntu-latest' }} name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:25], map[id:windows-latest name:Windows]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:17], map[id:${{ vars.UBUNTU_MEDIUM || 'ubuntu-latest' }} name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:17], map[id:windows-latest name:Windows]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:21], map[id:${{ vars.UBUNTU_MEDIUM || 'ubuntu-latest' }} name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:21], map[id:windows-latest name:Windows]) (push) Waiting to runDetails
Run CodeQL Analysis / run-analysis (push) Waiting to runDetails
Run System Tests / Java ${{ matrix.java.version}} (map[toolchain:true version:17]) (push) Waiting to runDetails
Run System Tests / Java ${{ matrix.java.version}} (map[toolchain:true version:21]) (push) Waiting to runDetails
Change `spring-boot-tomcat-runtime` and `spring-boot-jetty-runtime`
into starter POMs and reduce the number of dependencies needed for
`spring-boot-tomcat` and `spring-boot-jetty`.
The runtime starters provide only the jars required to run the
embedded server along with the module jar itself (excluding transitive
dependencies) and `spring-boot-webserver` (excluding transitive
dependencies).
The build setup required for an executable jar is slightly different
between Maven and Gradle. For Maven, the regular module is put in the
`provided` scope. For Gradle, the regular module remains in main
configuration and the runtime jar is put in the `providedRuntime`
configuration. The reference documentation has been updated to
show how to configure things if starters are being used.
Manual testing has been performed to ensure that wars build with Maven
and Gradle work with both Tomcat and Jetty in both deployed and
`java -jar` modes.
Closes gh-48175
Before this commit the meter registries were derived from the created
gauges. If the SslMeterBinder has been bound to a MeterRegistry without
any bundles, then no gauges are created. If a SslBundle is then
dynamically added, onBundleChange is called with the new bundle, but the
list of meter registries is empty (because we have no gauges). The
effect is that the newly registered bundle has no metrics.
Closes gh-48180
This commit adds spring-boot-starter-micrometer-metrics and
spring-boot-starter-micrometer-metrics-test.
It also uses the new starters in smoke tests and in other starters,
which depended on spring-boot-micrometer-metrics.
Closes gh-48161
Refine `buildSrc` so that `spring.mavenRepositories()` are considered
for all build types (not just milestones and snapshots). We now pass
"springFrameworkVersion" to `SpringRepositorySupport.groovy` so that
repo.spring.io doesn't get added for OSS builds using release artifacts.
Closes gh-46823
* pr/46818:
Polish "Fail fast with explicit error message for incompatible JDK version"
Fail fast with explicit error message for incompatible JDK version
Closes gh-46818
* pr/48141:
Polish "Elasticsearch starter should depend on elasticsearch-java"
Elasticsearch starter should depend on elasticsearch-java
Closes gh-48141
This commit moves mime-mapping.properties in the module that actually
uses it, rather than in the top-level spring-boot module.
See gh-48138
Signed-off-by: Stefan Würsten <stefan@wuersten.ch>
Initialize StringBuilder with the expected capacity (this.blank.length())
to avoid unnecessary resizing and array copying during string construction.
The blank field already contains the exact length needed for the formatted
output, making it an ideal initial capacity. This improves performance for
correlation ID formatting, which is frequently called during logging
operations.
See gh-48125
Signed-off-by: gobeomjun <alap_u@naver.com>
Change 'suppler' to 'supplier' in the `@param` documentation
for the throwIfPortBindingException method.
See gh-48124
Signed-off-by: gobeomjun <alap_u@naver.com>
When validating exclusions, prefer the selector's beanClassLoader for
ClassUtils.isPresent checks and fall back to the selector class loader
if the beanClassLoader is not set.
This makes presence checks consistent with the classloader context used
for loading auto-configuration candidates.
See gh-48129
Signed-off-by: linw-bai <107357009+linw-bai@users.noreply.github.com>
The two main changes are:
- A setter is no longer required when binding from a
comma-separated list as long as the target list is mutable. The
binder clears the list and then re-populates it.
- A setter is now required for arrays, previously the values
coming from configuration properties where merged into an existing
array. Now, the array is replaced.
Closes gh-43138
Build and Deploy Snapshot / Build and Deploy Snapshot (push) Waiting to runDetails
Build and Deploy Snapshot / Trigger Docs Build (push) Blocked by required conditionsDetails
Build and Deploy Snapshot / Verify (push) Blocked by required conditionsDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:17], map[id:${{ vars.UBUNTU_MEDIUM || 'ubuntu-latest' }} name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:17], map[id:windows-latest name:Windows]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:21], map[id:${{ vars.UBUNTU_MEDIUM || 'ubuntu-latest' }} name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:21], map[id:windows-latest name:Windows]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:24], map[id:${{ vars.UBUNTU_MEDIUM || 'ubuntu-latest' }} name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:24], map[id:windows-latest name:Windows]) (push) Waiting to runDetails
Run CodeQL Analysis / run-analysis (push) Waiting to runDetails
Run System Tests / Java ${{ matrix.java.version}} (map[toolchain:false version:17]) (push) Waiting to runDetails
Run System Tests / Java ${{ matrix.java.version}} (map[toolchain:true version:21]) (push) Waiting to runDetails
Update `DockerApi` and `Builder` to support export of images with a
specified platform. This prevents 'NotFound: content digest sha256:'
errors when building an amd64 image on an arm64 machine.
Fixes gh-46665
The issue had already been fixed in 4.0 as part of the nullability
work. As such, this commit doesn't fix anything. It does, however,
merge forward a test and makes some stylistic changes to the code so
that it's aligned with the same code in 3.5.x and 3.4.x
* pr/47980:
Polish "Add since to deprecations in config metadata JSON files"
Add since to deprecations in config metadata JSON files
Add since attribute to uses of DeprecatedConfigurationProperty
Closes gh-47980
Add the `since` field to all deprecated properties in all
additional-spring-configuration-metadata.json files in the project.
Add to the CheckAdditionalSpringConfigurationMetadata build task to
ensure that all deprecated properties have a non-empty `since` field.
See gh-47980
Signed-off-by: Scott Frederick <scottyfred@gmail.com>
Add an architecture rule to ensure that all usages of
`@DeprecatedConfigurationProperty` in the Spring Boot codebase include
the `since` attribute.
Add the `since` attribute to the few places where it was not already
included.
See gh-47980
Signed-off-by: Scott Frederick <scottyfred@gmail.com>
Update `DockerApi` so that the URL uses version `v1.50` whenever
possible. Prior to this commit, `v1.24` was often used which breaks
recent Docker installs due to the dropping of API version v1.43 and
below.
If the actual API version running is less than `v1.50`, but greater
than the minimum required for the API call, it will be used instead.
This hopefully means that older versions of Docker will continue to
work as they did previously.
Fixes gh-48050
Build and Deploy Snapshot / Build and Deploy Snapshot (push) Waiting to runDetails
Build and Deploy Snapshot / Trigger Docs Build (push) Blocked by required conditionsDetails
Build and Deploy Snapshot / Verify (push) Blocked by required conditionsDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:25], map[id:${{ vars.UBUNTU_MEDIUM || 'ubuntu-latest' }} name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:25], map[id:windows-latest name:Windows]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:17], map[id:${{ vars.UBUNTU_MEDIUM || 'ubuntu-latest' }} name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:17], map[id:windows-latest name:Windows]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:21], map[id:${{ vars.UBUNTU_MEDIUM || 'ubuntu-latest' }} name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:21], map[id:windows-latest name:Windows]) (push) Waiting to runDetails
Run CodeQL Analysis / run-analysis (push) Waiting to runDetails
Run System Tests / Java ${{ matrix.java.version}} (map[toolchain:true version:17]) (push) Waiting to runDetails
Run System Tests / Java ${{ matrix.java.version}} (map[toolchain:true version:21]) (push) Waiting to runDetails
This commit applies similar changes already contributed to the
`HttpMessageConverter` stack for MVC applications.
Since there was no auto-configuration for Kotlinx JSON Serialization on
the reactive side, this commit adds a relevant `CodecCustomizer` that
will use an available `Json` bean and use it to configure a codec that:
* will only consider `@Serializable`-annotated types if another JSON
library is available
* will use a broader support with Kotlinx Serialization otherwise
Fixes gh-48070
Prior to this commit, performing a build on a ARM Mac with the default
configuration and then building it again with the image platform set to
`linux/amd64` results in an "Image platform mismatch detected" failure.
This is due to the fact that `docker inspect` returns JSON for the
default platform, regardless of the fact that another architecture
has been pulled.
To solve the issue, the `inspect` API call on Docker 1.49+ can now
accept a platform query parameter which when specified returns platform
specific JSON.
At the time of this commit, the Docker API documentation hasn't been
updated, despite PR https://github.com/moby/moby/pull/49586 being
merged.
In addition to using the correct inspect JSON, we also need to pin
the run image we use to a specific digest. Without doing this,
buildpacks revert back to the default platform image and
"content digest not found" errors are thrown (similar to
https://github.com/buildpacks/docs/issues/818).
See gh-47292
Signed-off-by: hojooo <ghwn5833@gmail.com>
This commit ensures that XML and JSON converters on both client and
server are configured using the dedicated methods on
`HttpMessageConverters`, instead of pushing them ahead of default
converters.
Closes gh-47917
Fixes gh-48096
Build and Deploy Snapshot / Build and Deploy Snapshot (push) Waiting to runDetails
Build and Deploy Snapshot / Trigger Docs Build (push) Blocked by required conditionsDetails
Build and Deploy Snapshot / Verify (push) Blocked by required conditionsDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:17], map[id:${{ vars.UBUNTU_MEDIUM || 'ubuntu-latest' }} name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:17], map[id:windows-latest name:Windows]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:21], map[id:${{ vars.UBUNTU_MEDIUM || 'ubuntu-latest' }} name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:21], map[id:windows-latest name:Windows]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:25], map[id:${{ vars.UBUNTU_MEDIUM || 'ubuntu-latest' }} name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:25], map[id:windows-latest name:Windows]) (push) Waiting to runDetails
Run CodeQL Analysis / run-analysis (push) Waiting to runDetails
Run System Tests / Java ${{ matrix.java.version}} (map[toolchain:false version:17]) (push) Waiting to runDetails
Run System Tests / Java ${{ matrix.java.version}} (map[toolchain:true version:21]) (push) Waiting to runDetails
This commit adds a 'org.springframework.boot.configuration-metadata'
plugin to be used for projects that only define manual metadata. Such
project do not need the annotation processor, but do not to check that
the structure of the metadata content matches the same rules.
Closes gh-47984
Build and Deploy Snapshot / Build and Deploy Snapshot (push) Waiting to runDetails
Build and Deploy Snapshot / Trigger Docs Build (push) Blocked by required conditionsDetails
Build and Deploy Snapshot / Verify (push) Blocked by required conditionsDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:25], map[id:${{ vars.UBUNTU_MEDIUM || 'ubuntu-latest' }} name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:false version:25], map[id:windows-latest name:Windows]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:17], map[id:${{ vars.UBUNTU_MEDIUM || 'ubuntu-latest' }} name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:17], map[id:windows-latest name:Windows]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:21], map[id:${{ vars.UBUNTU_MEDIUM || 'ubuntu-latest' }} name:Linux]) (push) Waiting to runDetails
CI / ${{ matrix.os.name}} | Java ${{ matrix.java.version}} (map[toolchain:true version:21], map[id:windows-latest name:Windows]) (push) Waiting to runDetails
Run CodeQL Analysis / run-analysis (push) Waiting to runDetails
Run System Tests / Java ${{ matrix.java.version}} (map[toolchain:true version:17]) (push) Waiting to runDetails
Run System Tests / Java ${{ matrix.java.version}} (map[toolchain:true version:21]) (push) Waiting to runDetails
Tomcat 11 will [1] send a response as soon as Content-Length bytes has
been written. This initiates a race between the timer being registered
on the server side and the test receiving the response and looking for
the timer.
Rather than sleeping for a fix period of time, we now use Awaitility
to await the availability of the timer.
Closes gh-48049
[1] 69eff83577
Previously, Kotlin Serialization would be used too aggressively then
an alternative JSON converter was available. This could lead to
unwanted results when a response should have been serialized using
Jackson, for example, rather than Kotlin Serialization.
This commit addresses this by only allowing Kotlin Serialization to
serialize types that are not annotated with @Serializable when no
alternative JSON converter is available.
Fixes gh-48070
As of As of spring-projects/spring-framework#35733, Spring Framework has
a dedicated method for configuring a Kotlin Serialization converter
specifically.
This commit uses this method instead of configuring the Kotlin
Serialization JSON support as a custom converter. This also removes the
`@Order` on the Kotlin converter bean itself, as there is no need to
order it in the list of custom converters anymore.
Closes gh-47917
Previously, all destruction was done in the stop method including
closing any Closeables registered with the server. One of these
Closeables managed the lifecycle of the DeploymentManager for the
servlet deployment. Closing it made the servlet context unusable
in `@PreDestroy` methods and upon restart.
This commit moves the closing of the registered Closeables into
destroy(). This allows `@PreDestory` methods to use the
ServletContext. It also allows the server to be stopped and then
restarted without making the ServletContext unusable as it's left
running while the server itself is stopped and not accepting
requests.
Fixes gh-47141
This commit also tests that WebSecurityConfigurer components are
included. They include was already there but the functionality was
untested.
Fixes gh-47255
Replace calls to the recently deprecated `setConnectionTimeout` method
of `HttpComponentsClientHttpRequestFactoryBuilder`.
This commit also introduces a `withConnectionConfigCustomizer` and
allows connection timeouts settings to be used.
Closes gh-48031
Kafka 4.0 dropped support for Scala 2.12, so the
`kafka-streams-scala_2.12` and `kafka_2.12` libraries should not be
dependency-managed along with the rest of the Kafka 4.1.0 libraries.
See gh-47991
Signed-off-by: Scott Frederick <scottyfred@gmail.com>
This ensures that the runtime is packaged in the war file's `WEB-INF/lib-provided` directory from where it will not conflict with the external container's own classes.
This ensures that the runtime jars are packaged in the war file's `WEB-INF/lib-provided` directory from where they will not conflict with the external container's own classes.
NOTE: `providedRuntime` is preferred to Gradle's `compileOnly` configuration as, among other limitations, `compileOnly` dependencies are not on the test classpath so any web-based integration tests will fail.
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.
If you want to create Liquibase migrations which populate your test database, you can leverage https://docs.liquibase.com/reference-guide/changelog-attributes/what-are-contexts[Liquibase contexts].
See also the related https://www.liquibase.com/blog/contexts-vs-labels[blog post].
First, you need to configure Liquibase to use a different changelog when running the tests.
One way to do this is to create a Spring Boot `test` profile and put the Liquibase properties in there.
For that, create a file named `src/test/resources/application-test.properties` and put the following property in there:
In practical terms, this translates into adding a `context:@test` attribute to changesets containing test data, for example:
This changelog will be used when the tests are run and it will not be packaged in your uber jar or your container.
It includes the production changelog and then declares a new changeset, whose `runOrder: last` setting specifies that it runs after all the production changesets have been run.
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 javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation] annotated test classes.
And using `spring.liquibase.contexts=test` in environments where you would like changesets containing test data to be applied.
@ -252,17 +252,25 @@ https://www.openshift.com/[OpenShift] has many resources describing how to deplo
[[howto.deployment.cloud.aws]]
== Amazon Web Services (AWS)
Amazon Web Services offers multiple ways to install Spring Boot-based applications, either as traditional web applications (war) or as executable jar files with an embedded web server.
The options include:
Amazon Web Services provides several options that are suitable for running Spring Boot-based applications, either as containers, traditional web applications (war), or self-contained executable jar files.
Popular options are:
* Amazon Elastic Container Service (ECS)
* AWS Elastic Beanstalk
* AWS Code Deploy
* AWS OPS Works
* AWS Cloud Formation
* AWS Container Registry
Each has different features and pricing models.
In this document, we describe to approach using AWS Elastic Beanstalk.
[[howto.deployment.cloud.aws.ecs]]
=== Amazon Elastic Container Service (ECS)
Official https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html[Amazon ECS developer guide] provides comprehensive overview of platform's features and includes https://docs.aws.amazon.com/AmazonECS/latest/developerguide/getting-started.html[getting started guide] that walks you through the steps needed to get your containers up and running.
NOTE: Spring Boot applications can be packaged in Docker containers using techniques described in xref:reference:packaging/container-images/index.adoc[].
In addition to the developer guide, AWS also provides a https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-container-image.html[topical guide] for deploying containerized Java services on Amazon ECS using AWS Fargate.
TIP: Spring Boot auto-detects AWS ECS deployment environments by checking the environment for the `AWS_EXECUTION_ENV` variable.
You can override this detection with the configprop:spring.main.cloud-platform[] configuration property.
@ -278,8 +286,9 @@ You can either use the "`Tomcat Platform`" or the "`Java SE platform`".
==== Using the Tomcat Platform
This option applies to Spring Boot projects that produce a war file.
No special configuration is required.
You need only follow the official guide.
Follow the official guide and https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/tomcat-quickstart.html[Java on Tomcat tutorial].
NOTE: Creating deployable war for a Spring Boot application is described in xref:deployment/traditional-deployment.adoc[].
@ -287,51 +296,8 @@ You need only follow the official guide.
==== Using the Java SE Platform
This option applies to Spring Boot projects that produce a jar file and run an embedded web container.
Elastic Beanstalk environments run an nginx instance on port 80 to proxy the actual application, running on port 5000.
To configure it, add the following line to your `application.properties` file:
[configprops,yaml]
----
server:
port: 5000
----
[TIP]
.Upload binaries instead of sources
====
By default, Elastic Beanstalk uploads sources and compiles them in AWS.
However, it is best to upload the binaries instead.
To do so, add lines similar to the following to your `.elasticbeanstalk/config.yml` file:
[source,xml]
----
deploy:
artifact: target/demo-0.0.1-SNAPSHOT.jar
----
====
[TIP]
.Reduce costs by setting the environment type
====
By default an Elastic Beanstalk environment is load balanced.
The load balancer has a significant cost.
To avoid that cost, set the environment type to "`Single instance`", as described in https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environments-create-wizard.html#environments-create-wizard-capacity[the Amazon documentation].
You can also create single instance environments by using the CLI and the following command:
[source]
----
eb create -s
----
====
[[howto.deployment.cloud.aws.summary]]
=== Summary
This is one of the easiest ways to get to AWS, but there are more things to cover, such as how to integrate Elastic Beanstalk into any CI / CD tool, use the Elastic Beanstalk Maven plugin instead of the CLI, and others.
There is a https://exampledriven.wordpress.com/2017/01/09/spring-boot-aws-elastic-beanstalk-example/[blog post] covering these topics more in detail.
Follow the official guide and https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/java-quickstart.html[Java tutorial].
There are also community provided tutorials such as https://www.baeldung.com/spring-boot-deploy-aws-beanstalk[this one].
The final step in the process is to ensure that the embedded servlet container does not interfere with the servlet container to which the war file is deployed.
To do so, you need to mark the embedded servlet runtime dependency as being provided.
If you use Maven, the following example marks the servlet runtime (Tomcat, in this case) as being provided:
For Maven, you need to mark the embedded servlet container dependency as being `provided`.
For example:
[source,xml]
----
@ -43,20 +43,21 @@ If you use Maven, the following example marks the servlet runtime (Tomcat, in th
@ -37,6 +37,8 @@ NOTE: The CNB builder used for the images is `paketobuildpacks/builder-noble-jav
It has a small footprint and reduced attack surface. It does not include a shell and contains a reduced set of system libraries.
If you need more tools in the resulting image, you can use `paketobuildpacks/ubuntu-noble-run:latest` as the *run* image.
NOTE: You have to build your application with at least JDK 25, because Buildpacks use the same GraalVM native-image version as the Java version used for compilation.
@ -247,7 +247,7 @@ For more detail, see the following sections:
Spring Boot installs a '`whitelabel`' error page that you see in a browser client if you encounter a server error (machine clients consuming JSON and other media types should see a sensible response with the right error code).
NOTE: Set `server.error.whitelabel.enabled=false` to switch the default error page off.
NOTE: Set configprop:spring.web.error.whitelabel.enabled[] to `false` to switch the default error page off.
Doing so restores the default of the servlet container that you are using.
Note that Spring Boot still tries to resolve the error view, so you should probably add your own error page rather than disabling it completely.
The following Gradle example configures the necessary dependencies and a {url-gradle-docs}/resolution_rules.html#sec:module_replacement[module replacement] to use Tomcat in place of Reactor Netty for Spring WebFlux:
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.
If you are creating a war file, you can use a similar approach, but you must indicate provided dependencies:
TIP: See javadoc:org.springframework.boot.actuate.autoconfigure.endpoint.web.CorsEndpointProperties[] for a complete list of options.
[[actuator.endpoints.json]]
== JSON
When working with JSON, Jackson is used for serialization and deserialization.
By default, an isolated javadoc:tools.jackson.databind.json.JsonMapper[] is used.
This isolation means that it does not share the same configuration as the application's `JsonMapper` and it is not affected by `spring.jackson.*` properties.
To disable this behavior and configure Actuator to use the application's `JsonMapper`, set configprop:management.endpoints.jackson.isolated-json-mapper[] to `false`.
Alternatively, you can define your own javadoc:org.springframework.boot.actuate.endpoint.jackson.EndpointJsonMapper[] bean that produces a `JsonMapper` that meets your needs.
Actuator will then use it for JSON processing.
[[actuator.endpoints.implementing-custom]]
== Implementing Custom Endpoints
@ -674,8 +685,8 @@ with the `key` listed in the following table:
TIP: You can disable them all by setting the configprop:management.health.defaults.enabled[] property.
TIP: The `ssl` javadoc:org.springframework.boot.actuate.health.HealthIndicator[] has a "warning threshold" property named configprop:management.health.ssl.certificate-validity-warning-threshold[].
If an SSL certificate will be invalid within the time span defined by this threshold, the javadoc:org.springframework.boot.actuate.health.HealthIndicator[] will warn you but it will still return HTTP 200 to not disrupt the application.
You can use this threshold to give yourself enough lead time to rotate the soon to be expired certificate.
You can use this threshold to give yourself enough lead time to rotate the soon-to-be-expired certificate.
If an SSL certificate will become invalid within the period defined by this threshold, the javadoc:org.springframework.boot.actuate.health.HealthIndicator[] will report this in the details section of its response where `details.validChains.certificates.[*].validity.status` will have the value `WILL_EXPIRE_SOON`.
Additional javadoc:org.springframework.boot.actuate.health.HealthIndicator[] beans are enabled by default:
@ -1260,7 +1271,7 @@ The `info` endpoint publishes information about your process, see javadoc:org.sp
[[actuator.endpoints.info.ssl-information]]
=== SSL Information
The `info` endpoint publishes information about your SSL certificates (that are configured through xref:features/ssl.adoc#features.ssl.bundles[SSL Bundles]), see javadoc:org.springframework.boot.info.SslInfo[] for more details. This endpoint reuses the "warning threshold" property of javadoc:org.springframework.boot.health.info.SslHealthIndicator[]: if an SSL certificate will be invalid within the time span defined by this threshold, it will trigger a warning. See the `management.health.ssl.certificate-validity-warning-threshold` property.
The `info` endpoint publishes information about your SSL certificates (that are configured through xref:features/ssl.adoc#features.ssl.bundles[SSL Bundles]), see javadoc:org.springframework.boot.info.SslInfo[] for more details.
@ -29,6 +29,11 @@ Observability support relies on the https://github.com/micrometer-metrics/contex
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.
If you're working with javadoc:org.springframework.scheduling.annotation.Async[format=annotation] methods or use an javadoc:org.springframework.core.task.AsyncTaskExecutor[], you have to register the javadoc:org.springframework.core.task.support.ContextPropagatingTaskDecorator[] on the executor, otherwise the observability context is lost when switching threads.
This can be done using this configuration:
include-code::ContextPropagationConfiguration[]
For more details about observations please see the {url-micrometer-docs}/observation[Micrometer Observation documentation].
@ -82,6 +87,18 @@ The preceding example will prevent all observations whose name contains "denied"
[[actuator.observability.annotations]]
== Micrometer Observation Annotations support
To enable scanning of observability annotations like javadoc:io.micrometer.observation.annotation.Observed[format=annotation], 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], you need to set the configprop:management.observations.annotations.enabled[] property to `true`.
This feature is supported by Micrometer directly.
Please refer to the {url-micrometer-docs-concepts}/timers.html#_the_timed_annotation[Micrometer], {url-micrometer-docs-observation}/components.html#micrometer-observation-annotations[Micrometer Observation] and {url-micrometer-tracing-docs}/api.html#_aspect_oriented_programming[Micrometer Tracing] reference docs.
NOTE: When you annotate methods or classes which are already instrumented (for example, xref:reference:actuator/metrics.adoc#actuator.metrics.supported.spring-data-repository[Spring Data repositories] or xref:reference:actuator/metrics.adoc#actuator.metrics.supported.spring-mvc[Spring MVC controllers]), you will get duplicate observations.
In that case you can either disable the automatic instrumentation using xref:reference:actuator/observability.adoc#actuator.observability.preventing-observations[properties] or an javadoc:io.micrometer.observation.ObservationPredicate[] and rely on your annotations, or you can remove your annotations.
[[actuator.observability.opentelemetry]]
== OpenTelemetry Support
@ -101,24 +118,82 @@ Auto-configured attributes will be merged with attributes from the `OTEL_RESOURC
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].
NOTE: Spring Boot does not provide automatic exporting of OpenTelemetry metrics or logs.
Exporting OpenTelemetry traces is only auto-configured when used together with xref:actuator/tracing.adoc[Micrometer Tracing].
Other environment variables as described in https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/[the OpenTelemetry documentation] are not supported.
If you want all environment variables specified by OpenTelemetry's SDK to be effective, you have to supply your own `OpenTelemetry` bean.
WARNING: Doing this will switch off Spring Boot's OpenTelemetry auto-configuration and may break the built-in observability functionality.
First, add a dependency to `io.opentelemetry:opentelemetry-sdk-extension-autoconfigure` to get https://opentelemetry.io/docs/languages/java/configuration/#zero-code-sdk-autoconfigure[OpenTelemetry's zero-code SDK autoconfigure module], then add this configuration:
To enable scanning of observability annotations like javadoc:io.micrometer.observation.annotation.Observed[format=annotation], 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], you need to set the configprop:management.observations.annotations.enabled[] property to `true`.
This feature is supported by Micrometer directly.
Please refer to the {url-micrometer-docs-concepts}/timers.html#_the_timed_annotation[Micrometer], {url-micrometer-docs-observation}/components.html#micrometer-observation-annotations[Micrometer Observation] and {url-micrometer-tracing-docs}/api.html#_aspect_oriented_programming[Micrometer Tracing] reference docs.
The javadoc:org.springframework.boot.opentelemetry.autoconfigure.logging.OpenTelemetryLoggingAutoConfiguration[] configures OpenTelemetry's javadoc:io.opentelemetry.sdk.logs.SdkLoggerProvider[].
Exporting logs via OTLP is supported through the javadoc:org.springframework.boot.opentelemetry.autoconfigure.logging.otlp.OtlpLoggingAutoConfiguration[], which enables OTLP log exporting over HTTP or gRPC.
NOTE: When you annotate methods or classes which are already instrumented (for example, xref:reference:actuator/metrics.adoc#actuator.metrics.supported.spring-data-repository[Spring Data repositories] or xref:reference:actuator/metrics.adoc#actuator.metrics.supported.spring-mvc[Spring MVC controllers]), you will get duplicate observations.
In that case you can either disable the automatic instrumentation using xref:reference:actuator/observability.adoc#actuator.observability.preventing-observations[properties] or an javadoc:io.micrometer.observation.ObservationPredicate[] and rely on your annotations, or you can remove your annotations.
However, while there is a `SdkLoggerProvider` bean, Spring Boot doesn't support bridging logs to this bean out of the box.
This can be done with 3rd-party log bridges, as described in the xref:reference:actuator/loggers.adoc#actuator.loggers.opentelemetry[Logging with OpenTelemetry] section.
[[actuator.observability.opentelemetry.metrics]]
=== Metrics
The choice of metrics in the Spring portfolio is Micrometer, which means that metrics are not collected and exported through the OpenTelemetry's javadoc:io.opentelemetry.sdk.metrics.SdkMeterProvider[].
Spring Boot doesn't provide a `SdkMeterProvider` bean.
However, Micrometer metrics can be exported via OTLP to any OpenTelemetry capable backend using the javadoc:io.micrometer.registry.otlp.OtlpMeterRegistry[], as described in the xref:reference:actuator/metrics.adoc#actuator.metrics.export.otlp[Metrics with OTLP] section.
NOTE: Micrometer's OTLP registry doesn't use the `Resource` bean, but setting `OTEL_RESOURCE_ATTRIBUTES`, `OTEL_SERVICE_NAME` or configprop:management.opentelemetry.resource-attributes[] works.
If you or a dependency you include make use of OpenTelemetry's javadoc:io.opentelemetry.api.metrics.MeterProvider[], those metrics are not exported.
We strongly recommend that you report your metrics with Micrometer.
If a dependency you include uses OpenTelemetry's `MeterProvider`, you can include this configuration in your application to configure a `MeterProvider` bean, which you then have to wire into your dependency:
include-code::OpenTelemetryMetricsConfiguration[]
This configuration also enables metrics export via OTLP over HTTP.
[[actuator.observability.opentelemetry.tracing]]
=== Tracing
If Micrometer tracing is used, the javadoc:org.springframework.boot.micrometer.tracing.opentelemetry.autoconfigure.OpenTelemetryTracingAutoConfiguration[] configures OpenTelemetry's javadoc:io.opentelemetry.sdk.trace.SdkTracerProvider[].
Exporting traces through OTLP is enabled by the javadoc:org.springframework.boot.micrometer.tracing.opentelemetry.autoconfigure.otlp.OtlpTracingAutoConfiguration[], which supports exporting traces with OTLP over HTTP or gRPC.
We strongly recommend using the Micrometer Observation or Tracing API instead of using the OpenTelemetry API directly.
@ -341,7 +341,7 @@ To take full control over the client's configuration, define a javadoc:co.elasti
Additionally, a javadoc:co.elastic.clients.transport.rest5_client.low_level.sniffer.Sniffer[] is auto-configured to automatically discover nodes from a running Elasticsearch cluster and set them on the javadoc:co.elastic.clients.transport.rest5_client.low_level.Rest5Client[] bean.
Additionally, a javadoc:co.elastic.clients.transport.rest5_client.low_level.sniffer.Sniffer[] can be auto-configured to automatically discover nodes from a running Elasticsearch cluster and set them on the javadoc:co.elastic.clients.transport.rest5_client.low_level.Rest5Client[] bean.
You can further tune how javadoc:co.elastic.clients.transport.rest5_client.low_level.sniffer.Sniffer[] is configured, as shown in the following example:
[configprops,yaml]
@ -350,18 +350,17 @@ spring:
elasticsearch:
restclient:
sniffer:
enabled: true
interval: "10m"
delay-after-failure: "30s"
----
To disable auto-configuration of the Sniffer, set configprop:spring.elasticsearch.restclient.sniffer.enabled[] to `false`.
==== Connecting to Elasticsearch Using ElasticsearchClient
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.
If you use the `spring-boot-starter-elasticsearch` or have added `co.elastic.clients:elasticsearch-java` to the classpath, Spring Boot will auto-configure and register an javadoc:co.elastic.clients.elasticsearch.ElasticsearchClient[] bean.
The javadoc:co.elastic.clients.elasticsearch.ElasticsearchClient[] uses a transport that depends upon the previously described javadoc:co.elastic.clients.transport.rest5_client.low_level.Rest5Client[].
Therefore, the properties described previously can be used to configure the javadoc:co.elastic.clients.elasticsearch.ElasticsearchClient[].
@ -795,12 +795,8 @@ NOTE: The properties that map to javadoc:org.springframework.boot.context.proper
Such arrangement relies on a default empty constructor and getters and setters are usually mandatory, since binding is through standard Java Beans property descriptors, just like in Spring MVC.
A setter may be omitted in the following cases:
* Maps, as long as they are initialized, need a getter but not necessarily a setter, since they can be mutated by the binder.
* Collections and arrays can be accessed either through an index (typically with YAML) or by using a single comma-separated value (properties).
In the latter case, a setter is mandatory.
We recommend to always add a setter for such types.
If you initialize a collection, make sure it is not immutable (as in the preceding example).
* If nested POJO properties are initialized (like the `Security` field in the preceding example), a setter is not required.
* Pre-initialized Maps and Collections, as long as they are initialized with a mutable implementation (like the `roles` field in the preceding example).
* Pre-initialized nested POJOs (like the `Security` field in the preceding example).
If you want the binder to create the instance on the fly by using its default constructor, you need a setter.
Some people use Project Lombok to add getters and setters automatically.
@ -101,4 +101,4 @@ The preferred JSON-B implementation is Eclipse Yasson for which dependency manag
Auto-configuration for Kotlin Serialization is provided.
When `kotlinx-serialization-json` is on the classpath a https://kotlinlang.org/api/kotlinx.serialization/kotlinx-serialization-json/kotlinx.serialization.json/-json/[Json] bean is automatically configured.
Several `+spring.kotlin.serialization.*+` configuration properties are provided for customizing the configuration.
Several `+spring.kotlinx.serialization.json.*+` configuration properties are provided for customizing the configuration.
Caches can be created on startup by setting the configprop:spring.cache.cache-names[] property.
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.
For example, `infinispan-core-jakarta` and `infinispan-commons-jakarta` must be used in place of `infinispan-core` and `infinispan-commons` respectively.
For more details, see https://infinispan.org/docs/stable/titles/spring/spring.html[the documentation].
@ -56,6 +56,7 @@ NOTE: Your executable jar must include AOT generated assets such as generated cl
Spring Boot applications usually use Cloud Native Buildpacks through the Maven (`mvn spring-boot:build-image`) or Gradle (`gradle bootBuildImage`) integrations.
You can, however, also use {url-buildpacks-docs}/for-platform-operators/how-to/integrate-ci/pack/[`pack`] to turn an AOT processed Spring Boot executable jar into a native container image.
NOTE: You have to build your application with at least JDK 25, because Buildpacks use the same GraalVM native-image version as the Java version used for compilation.
First, make sure that a Docker daemon is available (see https://docs.docker.com/installation/#installation[Get Docker] for more details).
https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user[Configure it to allow non-root user] if you are on Linux.
Init parameters can be configured on the javadoc:jakarta.servlet.ServletContext[] using `server.servlet.context-parameters.*` properties.
For example, the property `server.servlet.context-parameters.com.example.parameter=example` will configure a `ServletContext` init parameter named `com.example.parameter` with the value `example`.
==== Scanning for Servlets, Filters, and listeners
@ -628,7 +636,7 @@ Common server settings include:
* Network settings: Listen port for incoming HTTP requests (`server.port`), interface address to bind to (`server.address`), and so on.
* Session settings: Whether the session is persistent (`server.servlet.session.persistent`), session timeout (`server.servlet.session.timeout`), location of session data (`server.servlet.session.store-dir`), and session-cookie configuration (`server.servlet.session.cookie.*`).
* Error management: Location of the error page (`server.error.path`) and so on.
* Error management: Location of the error page (configprop:spring.web.error.path[]) and so on.