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
Change the initial fix for OSX Java 1.6 compatibility by removing the
need for a direct `tools.jar` dependency.
It appears that `system` dependencies are always pulled in when
used in a Maven plugin. This makes the the dependency on `tools.jar`
particularly brittle since we need to make assumptions about where
the jar is located.
Since the tools jar is *only* needed for Spring Loaded support, the
plugin has now been updated to locate the jar programmatically and
call it via reflection. This should reduce the risk of problems when
using the plugin and at the very least isolate them to Spring Loaded
support.
(See original commit b8c4720)
Fixes gh-497
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
When repackaging an archive, the files in the resulting lib directory
must be zip files. If they're not zip files, the resulting archive
may fail to run (#324).
The previous approach was to consider an artifact's type when deciding
whether or not it should be packaged. The type is a string and, while
there are a number of well-known values, it can essentially be anything.
This caused a problem with an artifact incorrectly being identified as
being unsuitable for inclusion (#489).
This commit changes the approach. Rather than looking at an artifact's
type, it looks at the first four bytes of the archive's file. Only if
these header bytes matche that of a zip file is the artifact included.
This is a better match for the requirement that all files in lib be zip
files.
Fixes#489
Currently Spring Boot fails in Java 1.6 on Mac OS X due to the
"tools.jar" being integrated into classes.jar in the Apple version of
Java 6.
Apple fixed this with Java 7, but we should still support Java 6. We had
to roll back to maven-plugin-plugin 3.1 to make this work with Java 6
and 7.
All tests pass with Java 6 and Java 7.
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
We had been making a special case for logback.xml anyway, so
extending that to simply deleting recursively all of
src/main/resources (or equivalent) from target/classes (or
equivalent) seems like it's perfectly justifiable.
Fixes gh-451
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
Requires Loaded 1.1.5 (or better).
For Maven you can just add springloaded to the dependencies of the
spring-boot plugin (and also set MAVEN_OPTS=-noverify).
For Gradle add springloaded to the build dependencies (-noverify
can be added by the plugin).
In both cases there is also support for adding an arbitrary java agent
via configuration. Samples are provided in
spring-boot-sample-[simple,web-ui].
The ApplicationPlugin is only added if there is no JavaExec task
already present, and additionally it computes its own man class if
none is provided. So "gradle run" and "gradle bootRun" look
superficially similar, but "bootRun" has extra options, including
the agent and Loaded support.
Fixes gh-251, gh-183
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
Previously, the Gradle plugin would package all of a project's
dependencies in the jar's lib directory, irrespective of each
dependency's type. This led to non-jar artifacts being packaged in
the lib directory where only jar dependencies are expected. See #334
for an example failure.
This commit updates the Gradle plugin such that it only packages
dependencies of type jar, ejb, ejb-client, test-jar, or bundle. This
brings the Gradle plugin into line with the Maven plugin.
Fixes#334.
Update the `ArtifactsLibraries` used by the maven plugin to filter
based on artifact types. This prevent `.pom` files from accidentally
being packaged in `/libs` and ultimately resulting in 'Unable to find
ZIP central directory records' errors.
Fixes gh-324
Add `mainClass` property option to the Repackage task. If the property
is defined within a task, it works in the same way as if it defined
within the springBoot{} 'ext' properties section.
Option is valid only for that specific task where it is defined, and
will override option defined in springBoot{} ext properties.
Fixes gh-283
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()`.
