@@ -46,7 +46,7 @@ Spring Boot Loader compatible jar files should be structured in the following wa
...
@@ -46,7 +46,7 @@ Spring Boot Loader compatible jar files should be structured in the following wa
+-classes
+-classes
| +-mycompany
| +-mycompany
| +-project
| +-project
| +-YouClasses.class
| +-YourClasses.class
+-lib
+-lib
+-dependency1.jar
+-dependency1.jar
+-dependency2.jar
+-dependency2.jar
...
@@ -77,7 +77,7 @@ Spring Boot Loader compatible war files should be structured in the following wa
...
@@ -77,7 +77,7 @@ Spring Boot Loader compatible war files should be structured in the following wa
| +-com
| +-com
| +-mycompany
| +-mycompany
| +-project
| +-project
| +-YouClasses.class
| +-YourClasses.class
+-lib
+-lib
| +-dependency1.jar
| +-dependency1.jar
| +-dependency2.jar
| +-dependency2.jar
...
@@ -95,26 +95,26 @@ a traditional web container should be placed in `WEB-INF/lib-provided`.
...
@@ -95,26 +95,26 @@ a traditional web container should be placed in `WEB-INF/lib-provided`.
[[executable-jar-jarfile]]
[[executable-jar-jarfile]]
=== Spring Boot's "`JarFile`" class
=== Spring Boot's "`JarFile`" class
The core class used to support loading nested jars is
The core class used to support loading nested jars is
`org.springframework.boot.loader.jar.JarFile`. It allows you load jar
`org.springframework.boot.loader.jar.JarFile`. It allows you to load jar
content from a standard jar file, or from nested child jar data. When first loaded, the
content from a standard jar file, or from nested child jar data. When first loaded, the
location of each `JarEntry` is mapped to a physical file offset of the outer jar:
location of each `JarEntry` is mapped to a physical file offset of the outer jar:
[indent=0]
[indent=0]
----
----
myapp.jar
myapp.jar
+---------+---------------------+
+-------------------+-------------------------+
| | /lib/mylib.jar |
| /BOOT-INF/classes | /BOOT-INF/lib/mylib.jar |
| A.class |+---------+---------+|
|+-----------------+||+-----------+----------+|
| || B.class | B.class ||
|| A.class ||| B.class | C.class ||
| |+---------+---------+|
|+-----------------+||+-----------+----------+|
+---------+---------------------+
+-------------------+-------------------------+
^ ^ ^
^ ^ ^
0063 3452 3980
0063 3452 3980
----
----
The example above shows how `A.class` can be found in `myapp.jar` position `0063`.
The example above shows how `A.class` can be found in `/BOOT-INF/classes` in `myapp.jar`
`B.class` from the nested jar can actually be found in `myapp.jar` position `3452`
position `0063`. `B.class` from the nested jar can actually be found in `myapp.jar`
and `B.class` is at position `3980`.
position `3452` and `C.class` is at position `3980`.
Armed with this information, we can load specific nested entries by simply seeking to
Armed with this information, we can load specific nested entries by simply seeking to
the appropriate part of the outer jar. We don't need to unpack the archive and we
the appropriate part of the outer jar. We don't need to unpack the archive and we
...
@@ -141,11 +141,12 @@ file and it's used to setup an appropriate `URLClassLoader` and ultimately call
...
@@ -141,11 +141,12 @@ file and it's used to setup an appropriate `URLClassLoader` and ultimately call
There are 3 launcher subclasses (`JarLauncher`, `WarLauncher` and `PropertiesLauncher`).
There are 3 launcher subclasses (`JarLauncher`, `WarLauncher` and `PropertiesLauncher`).
Their purpose is to load resources (`.class` files etc.) from nested jar files or war
Their purpose is to load resources (`.class` files etc.) from nested jar files or war
files in directories (as opposed to explicitly on the classpath). In the case of the
files in directories (as opposed to explicitly on the classpath). In the case of
`[Jar|War]Launcher` the nested paths are fixed (`+lib/*.jar+` and `+lib-provided/*.jar+` for
`JarLauncher` and `WarLauncher` the nested paths are fixed. `JarLauncher` looks in
the war case) so you just add extra jars in those locations if you want more. The
`BOOT-INF/lib/` and `WarLauncher` looks in `WEB-INF/lib/` and `WEB-INF/lib-provided/` so
`PropertiesLauncher` looks in `lib/` in your application archive by default, but you can
you just add extra jars in those locations if you want more. The `PropertiesLauncher`
add additional locations by setting an environment variable `LOADER_PATH` or `loader.path`
looks in `BOOT-INF/lib/` in your application archive by default, but you can add
additional locations by setting an environment variable `LOADER_PATH` or `loader.path`
in `application.properties` (comma-separated list of directories or archives).
in `application.properties` (comma-separated list of directories or archives).
...
@@ -242,7 +243,9 @@ Environment variables can be capitalized with underscore separators instead of p
...
@@ -242,7 +243,9 @@ Environment variables can be capitalized with underscore separators instead of p
the default) as long as `loader.config.location` is not specified.
the default) as long as `loader.config.location` is not specified.
* `loader.path` can contain directories (scanned recursively for jar and zip files),
* `loader.path` can contain directories (scanned recursively for jar and zip files),
archive paths, or wildcard patterns (for the default JVM behavior).
archive paths, or wildcard patterns (for the default JVM behavior).
* `loader.path` (if empty) defaults to `lib` (meaning a local directory or a nested one if running from an archive). Because of this `PropertiesLauncher` behaves the same as `JarLauncher` when no additional configuration is provided.
* `loader.path` (if empty) defaults to `lib` (meaning a local directory or a nested one if
running from an archive). Because of this `PropertiesLauncher` behaves the same as
`JarLauncher` when no additional configuration is provided.
* Placeholder replacement is done from System and environment variables plus the
* Placeholder replacement is done from System and environment variables plus the
