Previously, JarURLConnection would fail when created with a URL that
began with jar:file:// as the double-slash is not included in jarFile.getUrl().getFile().
This commit updates JarURLConnection to normalise the value return from
url.getFile() to remove a double-slash when present.
Fixes gh-5287
Closes gh-5289
Previously, JarLauncher considered any entry whose name began with
BOOT-INF/classes/ as being a nested entry. This was incorrect as it
meant that subdirectories of BOOT-INF/classes/ would be added to the
classpath rather than just BOOT-INF/classes/ itself.
This commit updates JarLauncher so that only directory entries with a
name equal to BOOT-INF/classes are used.
Closes gh-5610
Previously, if a JarFile was created from a directory nested inside
another jar file, it would look for the manifest in
pathFromRoot/META-INF/MANIFEST.MF. This is incorrect as, unlike a
JarFile created from a jar file, the archives are one and the same
so the manifests should be too.
This commit updates JarFile so that its aware of how it was created
(direct from a file, from a nested directory, from a nested jar). If
it was created from a file or from a nested jar, it uses its manifest.
If it was created from a nested directory, it uses the manifest of the
root archive.
Closes gh-5609
Previously, if loader.path directly specified a jar file that contained
nested archives (.zip or .jar), launching would fail unless those
nested archives were uncompressed. However, if loader.path specified a
directory that contained such a jar file the launch would succeed. This
was because the nested archives within the jar were ignored.
This commit updates PropertiesLauncher so that its behaviour in the
scenarios described above is consistent by not looking for archives
nested with a jar that’s be specified on loader.path. The javadoc for
loader.path has also been updated to make it clear that loader.path
can points to directories or jar files, bringing it into line with
the reference guide.
Closes gh-3701
Following changes to LaunchedURLClassLoader made in 87fe0b2a, it is
no longer necessary for the launcher to load MainMethodRunner via
reflection as both the app class loader that the launcher URL class
loader share the same MainMethodRunner class.
This commit takes advantage of this by updating Launcher to instantiate
MainMethodRunner directly rather than via reflection, removing one
source of possible exceptions in the launcher.
As the MainMethodRunner is now loaded directly and its class is shared
between the two class loaders, there’s no longer a need for it to
implement Runnable. This allows it to throw Exception from its run
method, rather than having to wrap any Exception in a RuntimeException.
Lastly, rather than catching any exception thrown from the launch,
Launcher and its subclasses have been updated to allow this exception
to be thrown from the main method. This allows the Exception to reach
the JVM, to be processed by our registered uncaught exception handler,
and to trigger the JVM’s standard processing for exiting due to a
failure. This removes the need for the Launcher itself to call
System.exit(1) and ensures that the exception is only output to the
console if it hasn’t been registered as a logged exception.
Closes gh-5358
Previously, the default BuildInfo task created by the DSL was called
buildInfo. Due to Gradle's lack of namespacing for tasks, this meant
there was a slight risk that it could clash with another task. It
also didn't following the naming used by Boot's run task which is
named bootRun.
This commit renames the default BuildInfo task to bootBuildInfo to
match bootRun and to hopefully avoid clashes with tasks from other
plugins.
Closes gh-5518
Previously, FindMainClassTask would look for a property named main
on any class named run. This was based on the assumption that the
run task would be a JavaExec task (typically provided by the
application plugin). If the run task was not a JavaExec task (more
accurately, if it did not have a main property) this would result in
a build failure due to trying to read a non-existent property.
This commit updates FindMainClassTask to only use the main property
of the run task if the task is a JavaExec task. This guarantees that
the property will exist on the task, and unlike using any property
named main on a task named run, also guarantee that its value will
refer to a Java class with a main method.
Closes gh-5501
Previously, when defining a package for a class, LaunchedURLClassLoader
would use the manifest from the first location that contained the
required package. If the package was split across multiple locations,
this could lead to the manifest from a jar other than the one that
contains the class being used.
This commit updates LaunchedURLClassLoader so that it will use the
manifest of the jar file that contains the class which triggered the
definition of the package.
Closes gh-5485
LaunchedURLClassLoader preemptively defines the package for any
classes that it attempts to load so that the manifest from a nested
jar is correctly associated with the package. This can lead to a race
where the package is defined on two threads in parallel, resulting
in an IllegalArgumentException being thrown.
This problem was manifesting itself as a NoClassDefFoundError.
If the initialization of a class failed due to the above-described
IllegalArgumentException, subsequent attempts to use that class
would then fail with a NoClassDefFoundError.
This commit updates LaunchedURLClassLoader to catch the
IllegalArgumentException and then double-check that the package has
already been defined. This approach, including thrown an
AssertionError when the second check fails, is modelled on the
approach taken by URLClassLoader.
Closes gh-5464
The commit adds a new BuildInfo task that can be used to generate
a build.properties file, intended for inclusion in the Actuator's
info endpoint.
A default instance of the task can be configure using the plugin's
DSL:
springBoot {
buildInfo()
}
Additional properties can also be configured using the DSL:
springBoot {
buildInfo {
additionalProperties = [
'foo': 'bar'
]
}
}
When configured via the DSL, the Java plugin's classes task is
configured to depend on the build info task. Alternatively, if more
control is required, the task can be declared and configured manually:
task buildInfo(type: org.springframework.boot.gradle.buildinfo.BuildInfo) {
additionalProperties = [
'foo': 'bar'
]
}
classes {
dependsOn buildInfo
}
See gh-2559
This commit updates the Maven plugin to generate a
`META-INF/boot/build.properties` file with various build-specific
settings (group, artifact, name, version and build time). Additionally,
the plugin can be configured to write an arbitrary number of additional
properties.
A new `BuildProperties` bean is automatically exposed when such a file is
present. If that bean is present, an `InfoContributor` is automatically
created to expose that information under the `build` key.
As for the git contributor, it is possible to only display the core
settings or everything using the `management.info.build.mode` property.
See gh-2559
Previously, the Launcher would call ex.printStackTrace for any
exception that was thrown when launching the application. This was
unnecessary as the stack trace should already have been logged by
the application when it failed to start.
This commit removes the call to ex.printStackTrace, thereby allowing
an exception to be logged only once or not at all after successful
failure analysis.
Closes gh-5358
This commit allows to generate the packaged artifact only locally by
adding a new `attach` property. If `attach` is set to `false` explicitly,
only the main artifact is installed/deployed.
Closes gh-5258
Previously, Repackager used Java 8 APIs without protecting against the
possibility of a NoSuchMethodError on earlier versions of Java.
This commit wraps the Java 8 APIs in try-catch blocks to ensure
that they do not cause a failure on Java versions before 8, while
still making full use of Java 8's capabilities when available.
Closes gh-5280
Previously, Animal Sniffer checking of spring-boot-loader-tools
was disabled as it failed with an NPE. This has been fixed in
Animal Sniffer 1.15.
This commit upgrades Animal Sniffer to 1.15 and adds the necessary
annotations to suppress failures for safe usage of sun.* and Java 7
APIs.
Note that UsesUnsafeJava has been copied from spring-boot and made
package-private. This retains the clearer intent of the custom
annotation (versus @IgnoreJRERequirement) while avoiding the change
in the build order that would be necessary for
spring-boot-loader-tools to use the annotation from spring-boot.
Closes gh-5284
This commit enhances the default launch script to allow the default
values for LOG_FOLDER and PID_FOLDER to be set at build time. They
can now be set using the logFolder and pidFolder properties
respectively.
Closes gh-4787
Previously, JarURLConnection would corrupt a URL that contained a
mixture of encoded and unencoded double-byte characters. URLs that
only contained unencoded double-byte characters were not affected as
they are passed through as-is.
This commit updates JarURLConnection.JarEntryName to correctly handle
characters with a value that won't fit in a single signed byte (a
value greater than 127). Such characters are now URL encoded and then
written to the output stream as multiple bytes.
Closes gh-5194
When an application is run as an executable archive with nested jars,
the application's own classes need to be able to load classes from
within the nested jars. This means that the application's classes need
to be loaded by the same class loader as is used for the nested jars.
When an application is launched with java -jar the contents of the
jar are on the class path of the app class loader, which is the
parent of the LaunchedURLClassLoader that is used to load classes
from within the nested jars. If the root of the jar includes the
application's classes, they would be loaded by the app class loader
and, therefore, would not be able to load classes from within the
nested jars.
Previously, this problem was resolved by LaunchedURLClassLoader being
created with a copy of all of the app class laoder's URLs and by
using an unconventional delegation model that caused it to skip its
parent (the app class loader) and jump straight to its root class
loader. This ensured that the LaunchedURLClassLoader would load both
the application's own classes and those from within any nested jars.
Unfortunately, this unusual delegation model has proved to be
problematic. We have seen and worked around some problems with Java
Agents (see gh-4911 and gh-863), but there are others (see gh-4868)
that cannot be made to work with the current delegation model.
This commit reworks LaunchedURLClassLoader to use a conventional
delegate model with the app class loader as its parent. With this
change in place, the application's own classes need to be hidden
from the app class loader via some other means. This is now achieved
by packaging application classes in BOOT-INF/classes (and, for
symmetry, nested jars are now packaged in BOOT-INF/lib). Both the
JarLauncher and the PropertiesLauncher (which supports the executable
jar layout) have been updated to look for classes and nested jars in
these new locations.
Closes gh-4897
Fixes gh-4868
Previously, the Launcher was creating a new runner thread that would
call the application's main method. An exception thrown by this thread
is handled differently to one thrown by the JVM's main thread leading
to different exit behaviour. Furthermore, the separate thread isn't
actually necessary.
This commit removew the use of a separate runner thread from the
Launcher. This means that the JVM's exit behaviour will be consistent
and also removes the overhead of createing a starting an extra thread.
Closes gh-5006
Andy Wilkinson
Vladimir Tsanev
Christian Brunotte
Phillip Webb
Stephane Nicoll
Eric Bottard
Uwe Schaefer
Spring Buildmaster