Spring/spring-boot
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Split spring boot features into multiple sections

Browse Source 
See gh-27132
This commit is contained in:
Madhura Bhave
2021-06-22 18:06:49 -07:00
parent f06b784d6e
commit 32a1644cca
60 changed files with 1544 additions and 1287 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
spring-boot-project/spring-boot-docs/src/docs/asciidoc/deployment/cloud.adoc
View File

@@ -136,7 +136,7 @@ The preStop handler can be configured via the PodSpec in the pod's configuration
command: ["sh", "-c", "sleep 10"]
----
Once the pre-stop hook has completed, SIGTERM will be sent to the container and <<features#features.graceful-shutdown,graceful shutdown>> will begin, allowing any remaining in-flight requests to complete.
Once the pre-stop hook has completed, SIGTERM will be sent to the container and <<web#web.graceful-shutdown,graceful shutdown>> will begin, allowing any remaining in-flight requests to complete.
NOTE: When Kubernetes sends a SIGTERM signal to the pod, it waits for a specified time called the termination grace period (the default for which is 30 seconds).
If the containers are still running after the grace period, they are sent the SIGKILL signal and forcibly removed.

28
spring-boot-project/spring-boot-docs/src/docs/asciidoc/deployment/containers.adoc
View File

@@ -1,28 +0,0 @@
[[deployment.containers]]
== Deploying to Containers
If you are running your application from a container, you can use an executable jar, but it is also often an advantage to explode it and run it in a different way.
Certain PaaS implementations may also choose to unpack archives before they run.
For example, Cloud Foundry operates this way.
One way to run an unpacked archive is by starting the appropriate launcher, as follows:
[source,shell,indent=0,subs="verbatim"]
----
$ jar -xf myapp.jar
$ java org.springframework.boot.loader.JarLauncher
----
This is actually slightly faster on startup (depending on the size of the jar) than running from an unexploded archive.
At runtime you shouldn't expect any differences.
Once you have unpacked the jar file, you can also get an extra boost to startup time by running the app with its "natural" main method instead of the `JarLauncher`. For example:
[source,shell,indent=0,subs="verbatim"]
----
$ jar -xf myapp.jar
$ java -cp BOOT-INF/classes:BOOT-INF/lib/* com.example.MyApplication
----
NOTE: Using the `JarLauncher` over the application's main method has the added benefit of a predictable classpath order.
The jar contains a `classpath.idx` file which is used by the `JarLauncher` when constructing the classpath.
More efficient container images can also be created by <<features#features.container-images.building.dockerfiles,creating separate layers>> for your dependencies and application classes and resources (which normally change more frequently).