From 3f2dd30808d605c6332a62913b628bb7bb20e4f3 Mon Sep 17 00:00:00 2001 From: Dave Syer Date: Wed, 2 Oct 2019 04:54:34 -0700 Subject: [PATCH] Add some more notes on running exploded jar files See gh-18477 --- .../appendix-executable-jar-format.adoc | 33 ++++++++++++++++--- 1 file changed, 29 insertions(+), 4 deletions(-) diff --git a/spring-boot-project/spring-boot-docs/src/main/asciidoc/appendix-executable-jar-format.adoc b/spring-boot-project/spring-boot-docs/src/main/asciidoc/appendix-executable-jar-format.adoc index ebcf4adca3..85aa97e8cf 100644 --- a/spring-boot-project/spring-boot-docs/src/main/asciidoc/appendix-executable-jar-format.adoc +++ b/spring-boot-project/spring-boot-docs/src/main/asciidoc/appendix-executable-jar-format.adoc @@ -164,18 +164,43 @@ The classpath is deduced from the nested jars. [[executable-jar-exploded-archives]] -=== Exploded Archives -Certain PaaS implementations may choose to unpack archives before they run. +=== Containers and Exploded Archives +If you are running your application from a container, you can use the unexploded jar file as above, 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. -You can run an unpacked archive by starting the appropriate launcher, as follows: +The simplest way to run an unpacked archive is by starting the appropriate launcher, as follows: [indent=0] ---- - $ unzip -q myapp.jar + $ 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: + +[indent=0] +---- + $ jar -xf myapp.jar + $ java -cp BOOT-INF/classes:BOOT-INF/lib/* com.example.MyApplication +---- + +More efficient container images can also be created by copying the dependencies to the image as a separate layer from the application classes and resources (which normally change more frequently). +There is more than one way to achieve this layer separation. +For example, using a `Dockerfile` you could express it in this form (assuming the jar is already unpacked at `target/dependency`): + +[indent=0] +---- +FROM openjdk:8-jdk-alpine +VOLUME /tmp +ARG DEPENDENCY=target/dependency +COPY ${DEPENDENCY}/BOOT-INF/lib /app/lib +COPY ${DEPENDENCY}/META-INF /app/META-INF +COPY ${DEPENDENCY}/BOOT-INF/classes /app +ENTRYPOINT ["java","-cp","app:app/lib/*","com.example.MyApplication"] +---- [[executable-jar-property-launcher-features]] == `PropertiesLauncher` Features