Remove test-jar artifacts from Maven projects and relocate classes. The
majority of utilities now live in the `spring-boot-testsupport` module.
This update will help us to deploy artifacts using the standard Maven
deploy plugin in the future (which doesn't support the filtering of
individual artifacts).
Fixes gh-9493
Calling launch of PropertiesLauncherTests sets the thread context
class loader to an instance of LaunchedURLClassLoader. To avoid this
class loader being used beyond the scope of the test and launcher
that created it, this commit updates PropertiesLauncherTests to
capture the TCCL before each test and restore it after each test.
Closes gh-9378
Update `PropertiesLauncher` so that classes can be loaded outside of
`BOOT-INF/classes`. You can use a subdirectory, or the root directory
of an external jar (but not the parent archive to avoid issues
with agents and awkward delegation models).
Fixes gh-8480
Closes gh-8486
Previously, jars (either top-level or nested) in Zip64 format were
treated as normal jar files. This would lead to a failure later on
when an attempt was made to read an entry from the file.
This commit updates the loader to fail fast when it encounters a
Zip64 jar file. Such files are identified by the number of entries
in the central directory end record being 0xFFFF.
Closes gh-8735
The main changes are:
- Switch to `loader.properties` instead of `application.properties`
- Search for `loader.properties` in `loader.home` as well as in
the classpath
- Placeholder replacements in MANIFEST.MF (using `loader.properties`
or system/env vars)
See gh-7221
Closes gh-8346
Consider the following two URLs:
jar:file:/test.jar!/BOOT-INF/classes!/foo.txt
jar:file:/test.jar!/BOOT-INF/classes/foo.txt
They both reference the same foo.txt file in the BOOT-INF/classes
directory of test.jar, however the first URL does so via the
nested BOOT-INF/classes archive. Previously, this difference in the
URLs would lead to PathMatchingResourcePatternResolver returning two
resources for foo.txt when asked to find all resources matching the
pattern classpath*:/**/*.txt.
This commit updates our Handler that is used for jar: URLs to consider
the two URLs above to be equivalent such that url1 is equal to url2
and the two urls will produce the same hash code.
Closes gh-7449
Previously, if Boot's JarURLConnection pointed to the root of a nested
entry, e.g. /BOOT-INF/classes, a call to getInputStream() would throw
an IOException. This behavior is reasonable for a URL that points
to the root of a normal jar as the jar itself is on the class path
anyway. However, for a nested jar it meant that a call to
ClassLoader.getResources("") would not include URLs for any nested
jars and directories (/BOOT-INF/classes and jars in /BOOT-INF/lib).
This is due to some logic in URLClassPath.Loader.findResource that
verifies a URL by opening a connection and calling getInputStream().
The result of missing URLs for the root of nested jars and directories
is that classpath scanning that scans from the root (not a good idea
for performance reasons, but something that we should support) would
not find entries in /BOOT-INF/classes or in jars in /BOOT-INF/lib.
This commit updates our JarURLConnection so that it no longer throws
an IOException when asked for an InputStream for the root of a nested
entry (directory or jar).
Fixes gh-7003
This commit restores the logic in Handler that was changed when
d20ac56a was merged, while leaving the structural improvements intact.
In addition to a couple of changes where a typo meant the wrong
variable was being referenced, some logic branches now return false
rather than called super. This realigns our Handler's behaviour with
that of the JDK's.
Some more tests have also been added to try to catch the problems that
were introduced during the merge.
Closes gh-7021
Previously our handler didn't override parseURL or sameFile which
resulted in behaviour that differed from that of the JDK's handler.
Crucially, this would result in our JarURLConnection being passed
a spec that didn't contain a "!/". A knock-on effect of this was
that the connection would point to the root of the jar rather than
the intended entry.
Closes gh-7021
