Previously, RandomAccessDataFile used a semaphore and acquired it
interruptibly. This meant that an interrupted thread was unable to
access the file. Notably, this would prevent LaunchedURLClassLoader from
loading classes or resources on an interrupted thread.
The previous commit (937f857) updates RandomAccessDataFile to acquire
the semaphore uninterruptibly. This commit adds a test to
LaunchedURLClassLoader to verify that it can now load a resource from
an interrupted thread.
Closes gh-6683
Previously, if mvn spring-boot:run with a forked JVM was killed with
CTRL+C, the run would be considered unsuccessful. This commits updates
the run mojo to consider a forked JVM that exists with 130 (the exit
code produced when exiting due to SIGINT which is what CTRL+C sends) to
be successful.
Closes gh-6498
The unpack location is (largely) an implementation detail and the
Repackage Mojo was the only place where it was explicity documented.
Rather than updating the outdated location, this commit removes it
entirely to avoid encouraging people to rely on the location.
Closes gh-6624
META-INF/INDEX.LIST files are pointless in an executable jar and
moving application classes from the root of the jar to
BOOT-INF/classes breaks the index, resulting in an
InvalidJarIndexException being thrown.
This commit updates the Repackager to automatically remove a
META-INF/INDEX.LIST file from a jar file that is being repackaged.
Closes gh-6601
Where possible, code that previously synchronized on this (or on the
class in the case of static methods) has been updated to use an
internal monitor object instead. This allows the locking model that's
employed to be an implementation detail rather than part of the
class's API.
Classes that override a synchronized method continue to declare
the overriding method as synchronized. This ensures that locking
is consistent across the superclass and its subclass.
Closes gh-6262
Previously, if a property name had successive capital letters, the
generated meta-data would clean it in such a way it is defined as a
regular word. For instance a `myFOO` property would be written as
`my-foo` in the meta-data.
It turns out this decision is wrong as the binder has no way to compute
back the name of the property and therefore `my-foo` wouldn't bind to
`setMyFOO` as it should.
This commit updates the meta-data name generation algorithm to properly
identify such cases: `myFOO` now translates to `my-f-o-o`. While the
generated name is a bit ugly, it now provides a consistent binding
experience.
Closes gh-5330
This commit improves the performance of JarURLConnection. There are two
main changes:
Firstly, the way in which the spec is determined has been changed so
that it’s no longer necessary to create an absolute file. Instead,
the JarFile’s pathFromRoot is used to extract the spec from the URL
relative to the JarFile.
Secondly, the number of temporary Objects that are created has been
reduced, for example by tracking an index as we process a String
rather than creating a new substring for each iteration.
See gh-6215
JarURLConnection is very performance sensitive. The change in 3772d9f
meant that every JarURLConnection would create a FilePermission,
irrespective of whether it was actually used.
This commit updates JarURLConnection to create its FilePermission
lazily. When there is no security manager a permission will no longer
be created at all.
Closes gh-5411
See gh-6215
Previously, JarURLConnection assumed that that URL with which it was
created would contain the absolute path of the underlying jar file.
This meant that when it was created with a relative URL, it could fail
to find an entry or throw a StringIndexOutOfBoundsException.
This commit updates the logic for normalizing the input URL so that
both absolute and relative URLs are supported.
Closes gh-6109
This commit detects case where the same set of keys are exposed several
times and prevents the compilation to complete. Previously, duplicate
keys were silently added to the meta-data.
Closes gh-5939
In fact the folder was already created if the app is running as
a different user, but not if running as the current user, so it
was just a question of moving one line out of an if block.
Fixes gh-5986
Update TypeUtils to guard against the use of older Java versions.
Both `Collection` and `Map` type lookups now fallback to generic free
versions of the classes.
Prior to this commit using `xmlbeans-maven-plugin` in combination with
Spring Boot's annotation processor could result in
`IllegalArgumentException: Incorrect number of type arguments`.
Fixes gh-6122
Previously, Maven repositories definition was specified in a profile that
is active by default. It means that as soon as any profile is enabled by
the user, said profile is no longer enabled. This has the nasty
consequences of having copy/paste in several places to make sure our own
profiles still have the proper repositories definition.
This commit creates a single "repositories" profile that is always active
unless a given property is explicitely specified. This allows to remove
the duplication and make things more consistent.
Some Gradle-specific repositories were also hard-coded in two modules
without any profile at all, meaning they were polluting the build of
anybody using it. While the impacted modules are gradle specific, that
repository has been shared in the new "repositories" profile as well.
Closes gh-6031
Previously, JarURLConnection didn't override getPermission(). This
meant that it required all permissions. This was at odds with the
Oracle JVM's concrete sun.net.www.protocol.jar.JarURLConnection which
overrides getPermission to return a FilePermission with the read
action for the path of the underlying jar.
This commit updates our JarURLConnection to align its behaviour with
sun.net.www.protocol.jar.JarURLConnection.
Closes gh-5411
In Maven land, provided and system-scope dependencies are very similar,
the latter being an special kind that allows you to specify the path to
the artifact rather than using the repository to locate it.
Prior to this commit, the repackage goal of the maven plugin was
inconsistent as it would repackage provided-scope dependencies but would
ignore the system-scoped ones.
This commit adds an extra boolean flag, `includeSystemScope` to control
this behaviour. For backward compatibility reasons, its default value is
`false`.
Closes gh-2224
Previously, arguments passed to the script were handled in one way
if a service was being started using start-stop-daemon and in another
way if start-stop-daemon wasn’t available or the application is being
launched in run mode. This meant that quoted arguments were only
handled correctly when the application was being started using
start-stop-daemon.
This commit updates the launch script so that argument handling is
the same across all three different way that the application can be
launched.
Closes gh-5942
Using a separate thread to call the application's main method is
unnecessary – the context class loader of the current thread can be
updated instead – and makes exception and exit code handling more
complicated than it needs to be.
This commit updates the Launcher so that it calls the main method
runner using the current (main) thread. As a result, any exception
that's thrown will be caught by the JVM and result in a non-zero exit
code being returned from the process.
Closes gh-5922
Previously, if the folder which contained the jar was a symlink the
launch script would use the symlinked folder's name when determining
the default identity.
This commit updates the launch script so that symlinks are resolved
and the canonical name of the folder which contains the jar is used
when determining the script's default identity. The behaviour when
APP_NAME has been set is unchanged.
Closes gh-5679
Closes gh-5733
This commit improves the `InfoContributor` infrastructure as follows:
* `InfoEndpoint` no longer breaks its public API and returns a Map as
before
* `Info` is now immutable
* All properties of the build are now displayed. Since we control the
generation of that file, there is no longer a mode to restrict what's
shown
* Build info is now generated in `META-INF/build-info.properties` by
default
Closes gh-5734
Previously, if a void method with a single argument was named "set", the
annotation processor wrongly considered it was a setter candidate. This
commit updates the condition to ignore it.
Closes gh-5826
Previously, the Gradle plugin would include all of the dependencies
from both the compile and runtime configurations in the repackaged
jar. In the unlikely event that the compile and runtime configurations
contained different versions of the same dependency, this would lead
to both versions of the dependency being packaged in the jar file.
The runtime configuration extends the compile configuration so, in
normal circumstances, it will contain a superset of the compile
configuration's dependencies. In the situation described above where
the two configurations contain different versions of the same
dependency the runtime configuration will only contain whichever
version of the two dependencies has "won". By default, this will
be the dependency with the higher version.
This commit updates the Gradle plugin to only include the runtime
configuration's resolved dependencies during repackaging. As explained
above, the runtime configuration extends the compile configuration so
any compile dependencies will still be included, with the added
benefit that duplicate versions of the same dependency will have been
resolved to a single, preferred version.
Closes gh-5749
Previously, a JVM that was forked by spring-boot:run could be orphaned
when the parent process (the Maven build) was terminated in an IDE. Note
that this doesn’t happen when spring-boot:run is invoked from a shell.
This commits add a shutdown hook that registered when RunMojo forks the
JVM. The shutdown hook attempts to kill the forked JVM’s RunProcess
rather than relying on the death of the parent process being sufficient
to also kill the child.
Closes gh-5815
Update CentralDirectoryParser to reduce the number of objects created
when parsing the central directory. A single CentralDirectoryFileHeader
object is now reused as entries are parsed.
Fixes gh-5260
Previously, the CLI would always use the class loader to try to locate
a source file. This was contrary to the SourceOptions javadoc which
states that the class loader is “used to try and load files that are
not found in the local filesystem”. This provide to be problematic on
Windows when a fully-qualified source file was supplied. The driver
letter colon slash (e.g. c:/) at the start of the path is considered
invalid for a class path resource by URLClassPath.Loader resulting in an
IllegalArgumentException being thrown.
A workaround for this URLClassPath behaviour was added in a71c9b5d. It
was removed as part of reworking LaunchedURLClassLoader to use a
conventional delegation model in 87fe0b2a. It was then reinstated in
cc140b2c. This work around is undesirable as it causes
LaunchedURLClassLoader’s behaviour to diverge from URLClassLoader’s
behaviour (this is contrary to the comments in the test added in
a71c9b5d which incorrectly tests the two class loader with different
class paths. If the two class loaders are created with the same class
path then their behaviour is the same).
This commit updates SourceOptions to make its behaviour match its
javadoc so that a search of the class path is only performed if the
filename doesn’t exist on the filesystem. Furthermore, when running on
Windows, if the filename is an absolute path no further searching is
performed as the path cannot reliably be used to search the class path
due to the behaviour of URLClassPath.Loader when given a path that
is an absolute file path on Windows. This ensures that the user is
presented with an error message indicating that the file could not be
found.
Closes gh-5650
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
Andy Wilkinson
hengyunabc
Spring Buildmaster
Phillip Webb
Stephane Nicoll
Dave Syer
Tommy Ludwig
Christian Flamm
Johnny Lim
Jakub Narloch
Vladimir Tsanev
Christian Brunotte