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
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
Fix JarEntryData to re-read the local header, rather than relying on
the central directory record.
This protects against the situation where a JAR file is written with an
'Extra Field Length' that is different in the local header to the
central directory header.
This appears to be the case with aspectj 1.7.4 which contains the
following central directory file header for ProceedingJoinPoint:
50 4B 01 02 signature
14 03 version made by
0A 00 version required
00 00 general
08 00 compress methods
0E 40 59 43 last modified
2D 59 20 70 crc
EC 00 00 00 csize
8D 01 00 00 size
2A 00 fname len
00 00 ext field len
00 00 file comment len
00 00 disk num
00 00 int file att
00 00 A4 81 ext file att
97 F3 00 00 relative offset of the local file header
... file name
and the following local header:
50 4B 03 04 signature
0A 00 version required
00 00 general
08 00 compress method
0E 40 59 43 last modified
2D 59 20 70 crc
EC 00 00 00 csize
8D 01 00 00 size
2A 00 fname len
14 00 ext field len
... file name
... extra field
Note that the 'ext field len' is 0x00 in the central record but 0x14 in
the local record.
Fixes gh-203
Previous fix for handling wildcard entries in a classpath
imposed a new problem in a case where entry is a directory
with a jar files but also contains a lot of nested directories.
For example entry "./*" resulted for scanning whole disk starting
from "/". In case of default hadoop classpath, it scanned everything
under hadoop's installation. On some cases this deep scan was hidden
and was revealed by NPE's for file access exceptions.
When we want to support wildcard entries we only want to get
jar files from that directory, while boot itself have a need
to travel recursively to find classfiles from an expoded archive.
We handle this case by using recursive(true by default) flag in
ExplodedArchive and this flag is set to false in PropertiesLauncher
if we match wildcard.
PropertiesLauncher now supports creating its own class loader
from looader.classLoader property. It will succeed if the
implementation specified has a default constructor or one
that takes a parent class loader, or one that takes a URL[]
and a parent class loader (like URLClassLoader).
Phillip Webb
Dave Syer
Spring Buildmaster
Adam Brodziak
Andy Wilkinson
Janne Valkealahti
Guo Du