Previously, JarFileArchive would always unpack any entries marked for
unpacking to ${java.io.tmpdir}/spring-boot-libs. This could cause
problems if multiple Spring Boot applications were running on the same
host:
- If the apps are run as different users the first application would
create the spring-boot-libs directory and the second and subsequent
applications may not have write permissions to that directory
- Multiple apps may overwrite each others unpacked libs. At best this
will mean one copy of a jar is overwritten with another identical
copy. At worst the jars may have different contents so that some of
the contents of the original jar disappear unexpectedly.
This commit updates JarFileArchive to use an application-specific
location when unpacking libs. A directory beneath ${java.io.tmpdir} is
still used but it's now named <jar-file-name>-spring-boot-libs-<uuid>.
A loop, limited to 1000 attempts, is used to avoid problems caused by
the uuid clashing.
Closes gh-4124
The format is rather unusual.
The time is 16 bits: 5 bits for the hour, 6 bits for the minutes, and 5
bits for the seconds. 5 bits only allows 32 values (0-31) so the number
must be doubled, meaning that the time is only accurate to the nearest
two seconds. Also, the JDK rounds this down by subtracting one. The
doubling and rounding is performed by shifting one place to the left
and masking off the right-most bit respectively.
The date is 16 bits: 7 bits for the year, 4 bits for the month, and 5
bits for the day. The year is from 1980, i.e. the earliest date that
can be represented is 1980-01-01.
See http://mindprod.com/jgloss/zip.html for more details of the format.
Fixes gh-2826
Previously, WarLauncher included its root on the classpath. It also used
a filtered version of its root archive to hide both the WEB-INF and
META-INF directories. This meant that files in WEB-INF and META-INF
could be found by the classloader (as they were on the classpath) but
could not be read as the filtered archive was hiding them.
This commit updates WarLauncher to remove the root of the war file from
the classpath. It also removes the filtering of the archive, thereby
allowing files in META-INF and WEB-INF to be accessed via the
ServletContext.
Closes gh-1792
* Windows: allow absolute file paths without file:/// prefix
* All: only add nested archives (not directories), so loader.path=lib/*
behaves the same as -classpath=lib/* (except for adding zip files)
Fixes gh-1352
The ExplodedArchive would erroneously always attempt to filter
its contents (and thereby shield them from a classloader that wrapped
it) even if they haven't been explicitly provided.
See gh-1352
Fix 'fat jar' support for windows to correctly deal with URL and path
slash issues. The root cause of the original problem was caused by JAR
URLs not including a root slash (ie `file:C:/Users` vs `file:/C:/Users`)
Fixes gh-1145
Update the executable JAR code to automatically unpack any entries
which include an entry comment starting `UNPACK:` to the temp folder.
The existing Maven and Gradle plugins have been updated with new
configuration options and the `spring-boot-tools` project has been
updated to write the appropriate entry comment based on a flag passed
in via the `Library` class.
This support has been added to allow libraries such a JRuby (which
assumes that `jruby-complete.jar` is always accessible as file) to work
with Spring Boot executable jars.
Fixes gh-1070
Update JarURLConnection to allow the resolution of items within a nested
jar, even if the jarFile passed to the connection is several levels up.
This prevent a connection from incorrectly resolving an entry against
the wrong jar file.
See gh-1070
Update `spring-boot-loader` ZIP processing code to support prefixed
bytes within the fat jar. This technique allows a bash script to be
embedded at the start of the JAR whilst still allowing `java -jar`
execution.
Fixes gh-1073
ExecutableArchiveLauncher creates a ClassLoader that is used by the
Launcher to load an application’s classes. During the creation of this
ClassLoader URLs from another ClassLoader are copied over. This was
resulting in Java agents that are added to the system class loader
via the -javaagent launch option being available on both the system
class loader and the created class loader. Java agents are intended to
always be loaded by the system class loader. Making them available on
another class loader breaks this model.
This commit updates ExecutableArchiveLauncher so that it skips the URLs
of any Java agents (found by examining the JVM’s input arguments) when
copying URLs over to the new classloader, thereby ensuring that Java
agents are only ever loaded by the system class loader.
Fixes#863
The problem all along has been in AsciiBytes, so the fix in
commit ce3aaf was just a stop gap for a system where multi-byte
characters are supported but the default encoding is not UTF-8 (e.g.
most Windows systems). The real solution is not to leave it to
chance and always pick an encoding for the JarEntry names (i.e.
in AsciiBytes).
(Cherry picked from commit 06e364a9ff)
Fixes gh-764
The problem all along has been in AsciiBytes, so the fix in
commit ce3aaf was just a stop gap for a system where multi-byte
characters are supported but the default encoding is not UTF-8 (e.g.
most Windows systems). The real solution is not to leave it to
chance and always pick an encoding for the JarEntry names (i.e.
in AsciiBytes).
Fixes gh-764
Reverting arguments in assertEquals where constant was placed on
the "actual" place. Replacing assertEquals with assertFalse, assertTrue
and assertNull where applicable.
Fixes gh-735
Update the spring-boot-loader JarURLConnection class to decode entry
names in the same way as the stock JDK class. This allows encoded
entry names in the form `%c3%ab` to be loaded.
Fixes gh-556
It is sufficient for most purposes (e.g. the ones PropertieLauncher needs)
to only read the META-INF directory (not the whole file tree). So a quick
fix is to make META-INF a special case when initializing non-recursive
entries.
Fixes gh-520
The source of the exception is in sun.misc (so hard to track down precisely)
but it's clear that the LaunchedJarURLClassLoader needs to be more
defensive and return null from findResource() if it can't find it.
Fixes gh-486
This turns out to affect JPA, but only because it looks for a URL for the
root of the classpath using ClassLoader.getResource("") which barfs in
an app launched from an executable JAR. It's easy to make a special case
for "" in the class loader, so I went ahead and did that. Possibly need
to think what the implication of getResources("") is as well (not
tested in an app yet).
Fixes gh-420
It turns out that loader.path=. was pathological and before this
change ended up making the classpath empty (loader.path=.,lib/
would have fixed it). With this change the old behaviour is still
supported, but if the only user-supplied path entry is "." (or
empty) then it is now kept, and translates into the root of the
current archive if running as "java -jar ...".
Fixes gh-270
Restore previous behavior where JarFile URLs are always prefixed with
"jar:". I believe that the prefix is required in order to remain
compatible with standard JAR URLs.
This reverts commit 825fc2f7df.
Jetty apparently does it differently (different version of
Jasper maybe), so you need a unique jarFileURL for each
nested JAR (previously they were all set to the parent
archive URL).
Also added the root of the main archive as a valid
document root.
For gh-367
Update JarFile to allow the custom registration of a JAR
`URLStreamHandler` that allows `jar:` URLs to be constructed from
Strings. This removes the previous requirement that all nested JAR URLs
be created with a 'context'.
To supported nested JARs the `java.protocol.handler.pkgs` system
property is changed so that our custom URLHandler is picked for 'jar'
protocols in preference to the Java default.
Fixes gh-269
