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
The encoding of UTF-8 (et al.) chars in the
JarUrlConnection has to be made explicit, otherwise
Wdinows apparently does not pick the default(?).
Fixes gh-711, Fixes gh-753
The encoding of UTF-8 (et al.) chars in the
JarUrlConnection has to be made explicit, otherwise
Wdinows apparently does not pick the default(?).
Fixes gh-711, Fixes gh-753
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
Remove README files that have been since been migrated to the reference
documentation. Also updated remaining markdown files to asciidoctor to
save having a mix of different formats.
Fixed gh-503
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 the executable JAR `Handler` to fallback to the JVM handler if
the jar cannot be opened. This prevents exceptions when trying to
open URLs in the form "jar:jndi:/localhost...".
Fixes gh-347
Change CLI generated JARs to use the standard `JarLauncher` instead of
a custom `JarRunner`. The `PackagedSpringApplicationLauncher` is used
as the `Start-Class` which in turn calls `SpringApplication.run()`.
A new command, jar, has been added to the CLI. The command can be
used to create a self-contained executable JAR file from a CLI app.
Basic usage is:
spring jar <jar-name> <source-files>
For example:
spring jar my-app.jar *.groovy
The resulting jar will contain the classes generated by compiling the
source files, all of the application's dependencies, and entries
on the application's classpath.
By default a CLI application has the current working directory on
its classpath. This can be overridden using the --classpath option.
Any file that is referenced directly by the classpath is always
included in the jar. Any file that is found a result of being
contained within a directory that is on the classpath is subject to
filtering to determine whether or not it should be included. The
default includes are public/**, static/**, resources/**,
META-INF/**, *. The default excludes are .*, repository/**, build/**,
target/**. To be included in the jar, a file must match one of the
includes and none of the excludes. The filters can be overridden using
the --include and --exclude options.
Closes#241
Andy Wilkinson
Phillip Webb
Dave Syer
Artem Bilan
sopov.ivan
Spring Buildmaster
Martin Lau
Adam Brodziak