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
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
Ensure that JarFile caches are cleared once the ApplicationContext has
loaded. Caches are cleared manually with the assumption that no
further class loading is likely.
Closes gh-4882
Refactor `spring-boot-loader` to reduce the amount of memory required
to load fat & exploded jars. Jar files now no longer store a full list
of entry data records, but instead use an array of entry name hashes.
Since ClassLoaders often ask each JAR if they contain a particular
entry (and mostly they do not), the hash array provides a quick way to
deal with misses. Only when a hash does exist is data actually loaded
from the underlying file.
In addition to the JarFile changes, the Archive abstraction has also
been updated to reduce memory consumption.
See gh-4882
Remove the use of JDK loggers in Launcher and PropertiesLauncher to
ensure allow the custom Log4j2 `LogManager` to be used with Spring Boot
applications.
Fixes gh-3815
Commit 5a1ee6eb added support for disabling use of start-stop-daemon
via a placeholder in the default launch script. Unfortunately, that
placeholder was subsequently broken in 81a47639.
This commit reinstates the placeholder and adds tests to verify that all
of the placeholders in the launch script can be replaced and that they
have the required default values. Furthermore, it also allows the use of
start-stop-daemon to be configured via USE_START_STOP_DAEMON in an
app’s .conf file. This allows the configuration to be changed after the
app has been built.
Closes gh-4985
Previously, if an application’s main method threw an exception,
MainMethodRunner would catch the exception and call System.exit(1).
This meant that the JVM would exit, irrespective of whether or not
any non-daemon threads were running. In contrast, when an application’s
main method was invoked directly (in an IDE, for example) the JVM
would not exit if one or more non-daemon threads were running. This
is standard JVM behaviour that we should be consistent with in the
launcher.
This commit updates MainMethodRunner to wrap any exception thrown by an
application’s main method in a RuntimeException and rethrow it. This
alllows the JVM to handle the exception and use its normal rules for
deciding whether or not it should exit.
Closes gh-4984
Generalize the `skip` property to start and stop goals so that one
can control if the Spring Boot app is starting via a configuration
property.
Note that this only controls the Spring Boot Maven plugin and the
failsafe maven plugin should be updated accordingly.
Closes gh-4922
PropertiesLauncher creates a ClassLoader that is used by the Launcher
to load an application’s classes. During the creation of this
ClassLoader URLs from its ClassLoader. This resulted resulting in Java
agents that are added to the system class loader via the -javaagent
launch option being available on both the system class loader and the
created class loader. Java agents are intended to always be loaded by
the system class loader. Making them available on another class loader
breaks this model.
This is the same problem that was in ExecutableArchiveLauncher and
that was fixed in ee08667e (see gh-863).
This commit updates PropertiesLauncher so that it skips the URLs of
any Java agents (found by examining the JVM’s input arguments) when
copying URLs over to the new ClassLoader, thereby ensuring that Java
agents are only ever loaded by the system class loader.
Closes gh-4911
Previously, the default launch script would send SIGTERM once and then
wait for up to 60 seconds for the app to have stopped. If the service
was stopped immediately after being started the first SIGTERM would
occasionally be ignored (presumably because the JVM was not yet in a
state to handle it) causing the service stop request to fail.
This commit updates the launch script to resend SIGTERM to the process
if it's still running 30 seconds after the first SIGTERM was sent.
Closes gh-4941
$arguments needs to be split on spaces so it can’t just be wrapped
in quotes. This commit updates arguments to be an array that is then
expanded ("{arguments[@]}"). The use of @ and double quotes means that
it is expanded into all elements individually quoted.
See gh-4866
This commit completes the changes to consistently used static final
fields for Log instances that were started in ec2f33f9. Specifically it:
- Removes this. when accessing logger fields that are now static
- Renames some fields from log to logger
- Makes some logger fields static
See gh-4784
81a4763 introduced a regression when multiple RUN_ARGS or JAVA_OPTS were
configured. Rather than the JVM being launched with multiple arguments
all of the RUN_ARGS or JAVA_OPTS were passed as a single argument. This
caused unexpected behaviour and typically caused the application to fail
to start.
This commit updates the quoting of the arguments the are supplied when
launching the app using start-stop-daemon so that space-separated
entries in RUN_ARGS and JAVA_OPTS remain separate.
Closes gh-4866
Previously, the launch script used which to determine the availability
of start-stop-daemon. which isn’t available by default on all OSs.
For example, it’s not available by default on CentOS 5.
This commit updates the launch script to use type when determining if
start-stop-daemon is available. This improves the portability of the
script and makes the use of type consistent throughout the script.
Closes gh-4925
Previously, the launch script would wait for the pid file to exist
before continuing. This didn’t work 100% of the time as it left a
window where the file had been created but the PID had not been written
to it that could result in an incorrect report of the app failing to
start.
This commit updates the script to wait for the file to have a size
greater than zero before continuing. This ensures that the pid has
been written to the file before the pid is read from the file and used
to check that the process is running.
Closes gh-4923
Update exit code support to allow the ExitCodeGenerator interface to
be placed on an Exception. Any uncaught exception implementing the
interface and returning a non `0` status will now trigger a System.exit
with the code.
Fixes gh-4803
Ensure that Collections.isEmpty() is used to check if there are no
elements in a collections. This is more explicit and can be faster than
calling .size().
Closes gh-4783
Exiting with 0 when cd fails is likely to be incorrectly interpreted
as success so we should exit with a non-zero value. Ideally, the init
script status action would exit with 4 but, at the point when
the cd is performed, we don’t even know if we’re running as an init
script. Exiting with 1 seems to be a reasonable compromise as it’s
fine for the non init-script case as well as being correct for all
init script actions other than status.
See gh-4653
Allow users to easily opt-opt of using the start-stop-daemon in the
launch script. This may be required on distros that include older
versions.
Fixes gh-4732
Replace all new-line characters in multi-line pom descriptions before
inserting into the launcher script. Prior to this commit the shell would
attempt to execut the extra lines, for example:
<description>
A multi-line pom description that could do something terrible:
rm -r foo
</description>
Closes gh-4703
Some libraries like aspectj are using findResource to see the raw
bytecode of a class. It will even call findResource for every method of
every class of beans that are post processed. This can be significant
performance hit on startup when LaunchedURLClassLoader and there are a
lot of nested jars.
See gh-3640
Fixes gh-4557
There’s a race condition in start-stop-daemon when --make-pidfile and
--background are used together [1]. This race condition can lead to the
command returning before the PID file has been created. The missing PID
file then causes the launch script to incorrectly report that the
service failed to start.
This commit updates the launch script to wait for up to 10 seconds for
the PID file to be created when start-stop-daemon is used to launch the
app.
Closes gh-4524
[1] https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1036899
Some libraries like aspectj are using findResource to see the raw
bytecode of a class. It will even call findResource for every method of
every class of beans that are post processed. This can be significant
performance hit on startup when LaunchedURLClassLoader and there are a
lot of nested jars.
See gh-3640
Fixes gh-4557
Update the launch script so that the PID file is not longer removed at
the beginning of the stop method. Prior to this commit if a service
wasn't able to stop on the first run, it wasn't possible to use the
launch script anymore.
Fixes gh-4369
Closes gh-4371
The HUP signal was being used to stop the service and for some reason,
sometimes it was being ignored. This commit change forces the use of the
TERM signal (the default signal of kill).
Fixes gh-4378
Closes gh-4414
The Maven POM does all the dependency resolutions for the
spring-boot-antlib project. Delegating this task to Ivy, which is
buried deep in the Antrun/Antunit part of the build, makes any kind
of proxy configuration much more complex.
The ivysettings.xml already has the local M2 repository configured,
but because the folder "repository" is missing, the artifacts, already
downloaded by Maven cannot be resolved from this location.
The Spring and Maven Central repositories should be removed from the
ivysettings.xml files in order to force all resolves to be done through
the local M2 repository. The POM of joda-time version 2.8.1 has an
optional dependency to joda-convert 1.2, which lets the Ivy resolve
process fail, because this version of the joda-convert library was
not resolved by any of the Maven POMs. It seems as if Ivy does not
respect the optional scope, defined in the joda-time POM.
Pass proxy settings to the forked process to make the Gradle distribution download work
Create a gradle.properties file for each Gradle integration test and writes the forking
process' proxy settings as systemProp.http(s).Host/Port to the properties file.
This configures the external process with the right proxy settings to let it download
the Gradle distribution via the HTTP proxy server.
Added a hint for Windows users to get the core.autocrlf setting right
When the core.autocrlf setting under Windows is set to false for example
All files are not converted regarding their EOL characters to the
Windows format with CRLF at a line's end. There is a checkstyle
validation that checks that all files have the system's line endings
and in some test-cases the value from the system property "line.ending"
is used to check test output. So without the conversion, those checks
are going to fail, resulting in build errors.
Fixes gh-4367, fixes gh-3816
Previously, the meta-data annotation processor was taking the first
setter that match the property name it has to handle. Contrary to
getters that are enforced by a return type (no argument), multiple
setter candidates may exist.
If a property's type got narrowed over time, the original setter may
have been marked as Deprecated. As the annotation processor takes the
first setter that matches based on the name only, it may pick up the
deprecated one and therefore mark the property as being (wrongly)
deprecatede in the meta-data.
It turns out that checking for the actual type of the setter parameter
brought a side effect: some primitive properties may use the primitive
or the Wrapper counter part. This commit not only look at the proper
setter based on the type but also fallback on the wrapper (or) primitive
if necessary.
Closes gh-4338
By default, start-stop-daemon will chdir to the root directory before
starting the process. This prevents an application.properties file that
sits alongside the jar from being found.
This commit updates the call to start-stop-daemon to use --chdir to
set the working directory to that of the jar that’s being launched.
Closes gh-4281
Update the "INIT INFO section" of `launch.script` to include
`initInfoProvides`, `initInfoShortDescription` and `initInfoDescription`
property substitutions.
The Maven plugin has been updated to populate substitutions with
`${project.artifactId}`, `${project.name}` and `${project.description}`.
Fixes gh-4245
Flip the default value of `addResources` for both the Maven and Gradle
plugins. This effectively turns off static resources reloading and, more
importantly, the pruning of duplicate resources from the target
directory.
As devetools is our mainstram solution for such feature, the documantion
has been updated to reflect that.
Closes gh-4227
The init script spec [1] describes a number of requirements with which
our launch.script did not comply. This commit makes the following
corrections:
- Add support for force-reload which should be implemented by all
init scripts
- Don't fail restart if the service is already stopped or not running
- Consider stop to be successful if the service is already stopped
- Exit with 1 if stop fails (indicating a generic or unspecified error)
rather than 3 (unimplemented feature)
- Report a status of 1 if app is not running but the pid file exists
- Report a status of 3 if the app is not running (no pid file)
Closes gh-4231
[1] http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
Previously, the launch script would always use a file named
<appname>.log to capture the application's console output. This commit
adds a variable, LOG_FILENAME, for specifying the file name defaulting
to <appname>.log.
Fixes gh-4194
This commit adds a dedicated property to specify the active profiles to
use when running an application via the Maven plugin. This works also
on the command line using the `run.profiles` system property and is
consistently applied whether the process is forked or not.
Closes gh-4199
Update `launch.script` to use `start-stop-daemon` when possible to
manage daemon processes. When `start-stop-daemon` is not available `su`
is used.
Closes gh-4137
Add an `excludeDevtools` property to both the Maven and Gradle plugin
that removes `org.springframework.boot:spring-boot-devtools` (if
necessary) when repackaging the application.
Closes gh-3171
Gradle 2.0, and only 2.0, requires a Plugin implementation to be
public. The changes made in gh-4113 (9c14ed3) made the class
package-private.
Closes gh-4139
Previously, JarFileArchive would always unpack any entries marked for
unpacking to ${java.io.tmpdir}/spring-boot-libs. This could cause
problems if multiple Spring Boot applications were running on the same
host:
- If the apps are run as different users the first application would
create the spring-boot-libs directory and the second and subsequent
applications may not have write permissions to that directory
- Multiple apps may overwrite each others unpacked libs. At best this
will mean one copy of a jar is overwritten with another identical
copy. At worst the jars may have different contents so that some of
the contents of the original jar disappear unexpectedly.
This commit updates JarFileArchive to use an application-specific
location when unpacking libs. A directory beneath ${java.io.tmpdir} is
still used but it's now named <jar-file-name>-spring-boot-libs-<uuid>.
A loop, limited to 1000 attempts, is used to avoid problems caused by
the uuid clashing.
Closes gh-4124
Replace existing Groovy code with Java since the Groovy Eclipse tooling
currently forces the use of an old jdt plugin which has formatter bugs.
Fixes gh-4113
The recommended usage for the java executable is:
java [-options] -jar jarfile [args...]
This commit updates the default launch script to match this recommended
usage by moving -jar to be the last option, after both the
disableJarChecking system property and any JAVA_OPTS.
Closes gh-3930
Use "return" instead of "exit" where possible, especially in
function definitions.
Also fixed the exit codes to match the LSB spec for some specific
conditions (fixes gh-3521).
Fixes gh-3199, fixes gh-3535
Previously, manual meta-data were added to the existing set of entries
which could lead to duplicates if a manual entry is meant to complement
a property that is detected via the processor.
We now match the name and type of the item against the auto-detected
entries. If no match is found, we add the extra entry as we did before.
If a match is found we override the description, default value and
deprecation information.
Closes gh-3562
The annotation processor detects `@ConfigurationProperties` bean or
method definition and merges manual meta-data. The former step will fail
with a NPE if the annotation is not present on the classpath. This could
happen if the annotation processor is added to a module that is not
actually using Spring Boot.
We now have a defensive check that skips that steps but still attempts to
merge manual meta-data if present.
Closes gh-3720
When nested jars are being used, hasMoreElements requires opening a
connection for an entry in every nested jar. If that entry doesn't
exist, a FileNotFoundException is thrown to indicate that a particular
jar doesn't contain the requested entry. This exception is used to
indicate the lack of an entry and is then swallowed, i.e. its stack
trace is of no importance. This means that the performance of
hasMoreElements can be improved by switching on fast exceptions while
it's being called. When fast exceptions are switched on a general
purpose pre-initialized FileNotFoundException is thrown rather than
creating a new FileNotFoundException instance each time.
In certain situations, the use of fast exceptions as described above
can improve performance fairly significantly. The JRE's default SAAJ
implementation uses META-INF/services-based discovery for _every_
request that's handled by Spring Web Services. Each discovery attempt
results in hasMoreElements being called making its performance
critical to throughput.
See gh-3640
DevTools look for a main thread named "main". The maven plugin is
actually using a different value and there is no real reason to. This
change fixes DevTools support as long as forking is enabled.
See gh-3315
8673250 updated the plugin so that the application plugin is no longer
applied by default. This exposed three problems:
1. bootRepackage may run before findMainClass has run, leaving it with
an unknown main class.
2. findMainClass may run before the classes have been built, making it
unable to find the main class by examining the class files
3. The project's mainClassName property was still being used as a
convention for the bootRun task's main property. If the application
plugin has not be applied, then this property does not exist.
The first problem has been addressed by configuring bootRepackage to
depend on findMainClass.
The second problem has been addressed by configuring the main source
set's output as an input of findMainClass, and configuring findMainClass
to depend on the tasks that build the output.
The third problem has been addressed by only using the mainClassName
property if it exists and its value is not null. We then fallback to
using the mainClassName property on the project's extra properties in
the same way.
See gh-2679
Previously, the Spring Boot Gradle plugin would always apply the
application plugin to a project. It then piggy-backed on the application
plugin’s mainClassName and applicationDefaultJvmArgs properties for the
configuration of the bootRun task.
This commit updates the Spring Boot Gradle plugin so that it no longer
applies the application plugin. If the user applies the application
plugin then its configuration will be used, but it’s a no longer
requirement.
Users who do not need the application plugin, but who were using the
mainClassName or applicationDefaultJvmArgs properties will need to
change their builds as a result of this change as those properties will
no longer exist. As before, the mainClassName can be configured on the
springBoot extension:
springBoot {
mainClassName 'com.example.YourApplication'
}
The applicationDefaultJvmArgs property can be used, but it must now be
declared with the project's ext block. For example:
ext {
applicationDefaultJvmArgs = [ '-Dcom.example.property=true' ]
}
Closes gh-2679
Add a new @DeprecatedConfigurationProperties annotation which can be
used by the `ConfigurationMetadataAnnotationProcessor` to generating
meta-data deprecated blocks.
Fixes gh-3543
Previously, an item could only have a 'deprecated' boolean flag to
indicate that the property is deprecated. It is desirable to provide an
additional description for the deprecation as well as the name of the
property to use instead.
The `deprecated` boolean flag is now supported. Instead, a `deprecated`
object can be specified with two optional attributes: `reason` to provide
an explanation for the deprecation and `replacement` to refer to the
property that should be used instead. If none of them is present, an
empty deprecation object should be set.
For backward compatibility, the `deprecated` field is still set.
Deprecation information can only set via manual meta-data.
Closes gh-3449
If a field is initialized via a factory method taking a single argument,
we can relatively safely consider that said argument is a good
representation of its default value. This is typically the case for
Charset or MimeType instances.
We now make sure to detect such use case (i.e. method argument with a
single argument).
Closes gh-3482
I think this is safe, judging by the integration tests, but I'm not
putting it in 1.2.x until we've had some feedback on it. The
integration tests actually had a bug that was masking this problem
because they were merging Properties from the whole classpath instead
of picking the first available resource (which is generally what
we do in Spring Boot applications for application.properties for
instance).
Fixes gh-3048
Liquibase has a `changeLog` property that is definitely used as a
`Resource` but cannot be defined as such as the original String value
should be kept against an API we don't control.
Update the tests also to make it more clear that if hints are added
against a property that is detected automatically, said property still
keeps all its auto-discovered capabilities.
Closes gh-3457
Add a new `spring-boot-configuration-metadata` module that provides an
API to manipulate Spring Boot configuration meta-data. Can read meta-data
from arbitrary locations, though the standard
`META-INF/spring-configuration-metadata.json` location must be preferred.
Closes gh-1970
When writing a jar, once an entry has been written it will never be
overwritten, i.e. the first write of a given entry will win. Previously,
when repackaging a jar, the existing contents were written followed by
any libraries. This caused a problem when repackaged a WAR file and
a library needed to be unpacked as the existing entry in WEB-INF/lib
would prevent the library with the UNPACK comment from being written.
This was addressed in f761916b by inverting the order so libraries
would take precedence over entries in the source jar.
It’s now become apparent that this change in the order causes a problem
for users who are obfuscating their code. The obfuscated code exists in
the source jar but is also provided to the repackager in its original
form as a library. When libraries take precedence, this means that the
code in its original form ends up in the repackaged war and the
obfuscation is lost.
This commit updates the repackager to write libraries that require
unpacking first. This allows the UNPACK comment to be written even if
there’s also a source entry for the library. Next, source entries are
written. This allows obfuscated source entries to take precedence over
any unobfuscated library equivalents. Lastly, standard libraries that
do not require unpacking are written into the repackaged archive.
Closes gh-3444
Previously, if the repackaged file was different from the main artifact
of the build, the maven plugin wrongly considered that it should attach
the file with a classifier.
The outputDirectory is honored properly now, regardless of the fact a
classifier is defined or not.
Fixes gh-3177
Make sure to fail the build with a proper compilation error message if
the user-defined meta-data are invalid. For now, this takes care of the
JSON format but other checks may be added in the future.
Closes gh-3329
Improve the "hints" section of the metadata so that each hint can provide
the reference to a value provider.
A value provider defines how a tool can discover the potential values of
a property based on the context. The provider is identifed by a name and
may have an arbitrary number of parameters.
Closes gh-3303
Create a new section in the meta-data called "hints" where users can
provide hints about a given property. The most basic use case for now
is to provide a list of values that a property can have. Each value may
have a description.
This sample JSON provides a basic example for a property called `foo.mode`
that exposes 3 values: "auto", "basic" and "advanced".
```
"hints": [
{
"id": "foo.mode",
"values": [
{
"value": "auto",
"description": "Some smart description."
},
{
"name": "basic"
},
{
"name": "advanced"
}
]
}
]
```
This information can be read by tools (such as IDE) and offer an
auto-completion with the list of values.
Closes gh-2054
Update the embedded launch script to include a `chkconfig` comment. This
solves the "Service doesn't support chkconfig" error when executing
the chkconfig command.
Fixes gh-3115
Update the launch script used in fully executable jars to:
- Include LSB-Header comments
- Source `.conf` files either next to the jar for additional script
configuration
Fixes gh-3243
Update the Maven and Gradle repackage tasks so that the embedded
startup script is no longer included by default. This change is
primarily due to the `cf` command line not currently accepting
the unusual jar format.
Fixes gh-3045
Do not rely on the packaging type to figure out what the extension of the
main artifact will be. So far, using `jar` and `war` packaging for `.jar`
and `.war` files worked by chance.
We know retrieve the actual extension as provided by Maven's
`ArtifactHandler`.
Fixes gh-2762
- Verify that isReady has been called
- When forking, use a random port for JMX
- Don’t wait for application termination as it introduces a race
condition and verifying that shutdown has been requested is
sufficient
See gh-2525
SpringApplicationLifecycle provides basic lifecycle operations on the
current Spring Boot application (that is checking if the application has
fully started and gracefully terminate the app). It can be registered as
an MBean of the platform MBean server if a specific property is set.
The Maven plugin uses that MBean to check that the application is ready
before ending the "start" phase. It uses it to trigger a proper shutdown
of the application during the "stop" phase.
If the process has to be forked, the platform MBean server is exposed on
a configurable port so that the maven plugin can connect to it.
Such change permits the maven plugin to integrate a classical integration
test scenario where the "start" goal is invoked during the
pre-integration phase and the "stop" goal during the post-integration
phase.
Closes gh-2525
Some of the features of the launch.script were not exposed for users
to be able to control at runtime. It now accepts things like
PID_FOLDER and LOG_FOLDER as environment variables, and also adopts
a clear naming convention where only the inputs are UPPER_CASE.
Previously, the CLI’s dependency management used proprietary Properties
file-based metadata to configure its dependency management. Since
spring-boot-gradle-plugin’s move to using the separate dependency
management plugin the CLI was the only user of this format.
This commit updates the CLI to use Maven boms to configure its
dependency management. By default it uses the spring-boot-dependencies
bom. This configuration can be augmented and overridden using the new
@DependencyManagementBom annotation which replaces @GrabMetadata.
Closes gh-2688
Closes gh-2439
This reverts commit b1c0a7cda4.
The plugin publishing process has moved to a new plugin-based approach
that brings with it some significant limitations:
- There's no staging to allow the promotion of good release builds
- There's no easy way to upload an existing artifact
- There's no control over the published pom.
The risk brought by these limitations, particularly the first, are
too great so we will no be publishing the Boot plugin to the Portal
until they're resolved.
Changing the plugin's ID was a breaking change that would require
users to do some work when they upgrade to Boot 1.3. The ID of the
plugin was changed purely so that it met the Portal's requirements.
Given that the plugin will not be published to the Portal for the
foreseaable future there's no need for us to inflict a breaking change
on people when there will be no benefit.
See gh-1567
Update JarWriter to set the entry timestamp for nested jars. The
timestamp is set to same time as the first (non directory) entry in
the nested jar.
This change should make it easier to created layered docker images.
Fixes gh-2807
SpringApplicationLifecycle provides lifecycle operations on the current
Spring Boot application. It can be registered as an MBean of the platform
MBean server if a specific property is set. Besides, the JMX name can
also be customized via a property in case more than one Spring Boot
application is started in the same process.
The Maven plugin uses that MBean to check that the application is ready
before ending the "start" phase. It uses it to trigger a proper shutdown
of the application during the "stop" phase.
If the process has to be forked, the platform MBean server is exposed on
a configurable port so that the maven plugin can connect to it.
Such change permits the maven plugin to integrate a classical integration
test scenario where the "start" goal is invoked during the
pre-integration phase and the "stop" goal during the post-integration
phase.
Closes gh-2525
The format is rather unusual.
The time is 16 bits: 5 bits for the hour, 6 bits for the minutes, and 5
bits for the seconds. 5 bits only allows 32 values (0-31) so the number
must be doubled, meaning that the time is only accurate to the nearest
two seconds. Also, the JDK rounds this down by subtracting one. The
doubling and rounding is performed by shifting one place to the left
and masking off the right-most bit respectively.
The date is 16 bits: 7 bits for the year, 4 bits for the month, and 5
bits for the day. The year is from 1980, i.e. the earliest date that
can be represented is 1980-01-01.
See http://mindprod.com/jgloss/zip.html for more details of the format.
Fixes gh-2826
Update the Maven and Gradle plugin to generate fully executable jar
files on Unix like machines. A launcher bash script is added to the
front of the jar file which handles execution.
The default execution script will either launch the application or
handle init.d service operations (start/stop/restart) depending on if
the application is executed directly, or via a symlink to init.d.
See gh-1117
Gradle’s plugin portal requires each plugin’s ID to be in a namespace.
Our existing ID, spring-boot, does not meet this requirement. This
commit changes the plugin’s ID to org.springframework.boot.spring-boot.
Note that, as is recommended [1], the plugin’s ID does not include
“gradle”.
See gh-1567
[1] http://plugins.gradle.org/submit
Following the move to using the separate dependency management plugin
this test is no longer valid. It should have been removed as part of
2c3c62d7
See gh-2133
This commit replaces Spring Boot's basic dependency management support
with separate dependency management plugin. This has a number of
benefits including:
1. A Maven bom can be used rather than a custom properties file
2. Dependency management is applied transitively rather than only to
direct dependencies
3. Exclusions are applied as they would be in Maven
4. Gradle-generated poms are automatically configured with the
appropriate dependency management
Closes gh-2133
Previously repackaging of an archive was performed in three steps:
1. Write the manifest
2. Write entries from the source archive into the destination
3. Write any libraries into the destination if they’re not already there
This worked fine for jar files, but not for war files. In the war file
case the libraries are already in the source archive’s WEB-INF/lib
directory so they’re copied into the destination in step 2. This means
that step 3 largely becomes a no-op and, crucially, the UNPACK comment
is not applied to any libraries that require it.
This commit reorders steps 2 and 3 so that the libraries are copied into
the destination first (allowing the UNPACK comment to be written, if
required) and then any entries in the source are written into the
destination if they’re not already there.
Fixes gh-2588
Update ConfigurationMetadataAnnotationProcessor so that `prefix` is
only obtained when the annotation is not null. Also improve exception
message by including the element.
Parse a version using our version format or any version that complies
with Major.Minor.Patch. Also add a VersionRange utility that can
determine if a given version is withing that range.
Closes gh-2494
The Maven plugin allows spring-boot:run to be configured so that
resources are loaded from their output location rather than from
src/main/resources. This commit adds an equivalent configuration
option to the Gradle plugin. To disable source resources from being
added to the classpath in place of those in the output location
the configure the bootRun tasks like this:
bootRun {
addResources = false
}
Closes gh-2431
The main change in this commit is to introduce a new BuildHandler
abstraction. A BuildHandler is responsible for producing the metadata
for a build. Two implementations are provided; one for standard builds
and one for incremental builds. This change means that the annotation
processor is no longer concerned with the two different build types
and can use the same logic in each case.
The code for reading and writing metadata files has also been moved
out into a separate class, MetadataStore, to allow it to be easily
utilised from multiple places.
Closes gh-2313
This commit udpdates the metadata annotation processor so that change
data from an incremental build is merged with the metadata from the
previous build.
Closes gh-2321
This commit adds support for configuring the XA DataSource and
ConnectionFactory pools created by Atomikos and Bitronix via the
environment. The property prefixes vary depending on the transaction
manager that’s in use. They are:
Bitronix:
- spring.jta.bitronix.datasource
- spring.jta.bitronix.connectionfactory
Atomikos:
- spring.jta.atomikos.datasource
- spring.jta.atomikos.connectionfactory
The configuration processor has been updated to ignore
javax.jms.XAConnectionFactory and javax.sql.XADataSource as neither of
these types can be created via property binding.
Closes gh-2027
By default, when building a project's jar its runtime dependencies
are not taken into account as they are not needed to successfully
compile the code that will be packaged in the jar. A side-effect of
this was that, if a project that was being repackaged had a runtime
dependency on another project, then the repackaged jar would not
include the jar of the project on which it has the runtime dependency
as the jar had not been built.
This commit updates Boot's repackage task to have a dependency on the
jar task of any project dependencies in the runtime configuration
thereby ensuring that those dependencies' jars will have been built
before the repackaging occurs.
Fixes gh-2344
Running the invoker plugin with multiple threads against an empty
Maven cache results in strange build failures where Maven claims that
it cannot find a jar or pom file for an artifact that it should be
able to find. It would appear that Maven is unable to cope with
concurrent writes to its cache.
This commit removes the usage of multiple threads that was introduced
in 4e907f1.
Fixes gh-2389
This test covers the code path that caused gh-2361 and also checks that,
when an additional metadata file is found, it’s correctly merged with
the other metadata.
Closes gh-2361
When running in Eclipse, by default Gradle builds its output into a
folder named bin. This commit update the annotation processor to remove
the failure assumption that the output will always be located beneath
a folder named classes.
Closes gh-2369
See gh-2361
If user runs an executable archive then it and its lib directory will be
on the classpath. Entries from loader.path take precedence in a way that
should make sense to users (earlier wins like in CLASSPATH env var).
Also added new integration tests to verify the behaviour (big improvement
on the old ones, which probably aought to be beefed up to the same
standard).
Fixes gh-2314
Update the @SupportedSourceVersion annotation to RELEASE_8 since it
should indicate "the latest source version an annotation processor
supports".
Fixes gh-2302
Update ConfigurationMetadataAnnotationProcessor to find the additional
metadata json file using createResource rather than getResource. Prior
to this commit the file could be skipped when multiple files were
contained on the classpath.
Fixes gh-2271
Previously, disabling forking was not possible if JVM arguments or an
agent are specified, even if the fork attribute is explicitly set to
`false`.
The fork attribute is now detected as it should and forking is disabled
when the fork attribute is set to false, even if JVM arguments or an
agent is either specified or discovered.
Fixes gh-2220
Previously, no configuration properties were discovered on a class using
lombok instead of regular getters/setters.
This commit adds a support for some of the lombok annotations,
specifically that is @Data, @Getter and @Setter. Provides the same
semantic as what lombok is generating.
Closes gh-2114
Previously, non camel case properties were wrongly resolved, i.e.
getFOO() leading to a 'f-o-o'. While unusual, underscores can also be
added to a property name. In that case, the hyphen should not be added
as the binder consider this to be a single "word". Typically setFoo_Bar
on the "something" prefix is mapped using "something.foo_bar".
All these cases are now handled properly, generating the target name that
the binder expects.
Fixes gh-2118
flyway.init and flyway.target are two options that are missing from the
meta-data following the change in f0bc3c0. It turns out that both these
properties have an additional setter taking a String so they shouldn't be
excluded after all
Closes gh-2088
Previously, a property holding an array did not have a proper default
value in the meta-data even though the related field was initialized
properly.
An explicit support for arrays has been added. The "defaultValue" now
holds the default value for singular properties or an array of values for
array-based properties. If the value is initalized with an empty array,
the default value is an empty array as well.
Closes gh-1996
Previously, any valid property was added to the meta-data of the current
group. This can be annoying for types that are not meant to be bound from
a simple string value. ClassLoader is one example.
A list of well-known types has been added: if the property type matches
an element of this list, it is ignored.
Fixes gh-2012
Previously, any property defined in a @Deprecated class were not marked
as deprecated as only the getter or field was inspected for the
annotation.
An additional check on the class has been added to handle this case.
Fixes gh-2014
Update the ConfigurationMetadataAnnotationProcessor nested class
algorithm to prevent inner classes being added as both groups and
properties.
Fixes gh-1975
Previously, an Enum that is defined as an inner class of a
@ConfigurationProperties pojo was wrongly detected as an nested group.
This case is now handled explicitly and covered by a test.
Fixes gh-1971
Add a companion module that IDE developers can use to read configuration
metadata from multiple sources into a single repository.
ConfigurationMetadataRepository provides access to groups and items as
well as an harmonized view on "sources" (that is the POJOs that have
contributed to a given group).
Closes gh-1970
Add a 'module' layout for the repackager which includes all 'compile'
and 'runtime' scope dependencies and does not require a main class.
Fixes gh-1941
Previously, WarLauncher included its root on the classpath. It also used
a filtered version of its root archive to hide both the WEB-INF and
META-INF directories. This meant that files in WEB-INF and META-INF
could be found by the classloader (as they were on the classpath) but
could not be read as the filtered archive was hiding them.
This commit updates WarLauncher to remove the root of the war file from
the classpath. It also removes the filtering of the archive, thereby
allowing files in META-INF and WEB-INF to be accessed via the
ServletContext.
Closes gh-1792
Update TypeElementMembers to correctly detect builder style setters.
The previous logic could fail because of the crazy way that TypeMirror
implements its equals() method.
Fixes gh-1859
See gh-1854
Previously, a setter method that was returning the current instance was
not identified as a "setter" by the configuration processor. As a result,
builder-style APIs were not covered by the configuration metadata.
If a setter returns either void or the current class, it is now
recognized as a valid setter.
Fixes gh-1854
Update ConfigurationMetadataAnnotationProcessor to ensure that only
local `additional-spring-configuration-metadata.json` files are merged
with the final output.
See gh-1830
Update ConfigurationMetadataAnnotationProcessor so that it gets called
even if the source code doesn't include any @ConfigurationProperties
items.
See gh-1830
Add a @NestedConfigurationProperty annotation which can be used to
customize how configuration mete-data is generated.
Prior to this commit only inner-classes where considered nested
(see Tomcat in ServerProperties). Using this new annotation, the Ssl
property in ServerProperties can be detected as well.
See gh-1001
Update `ConfigurationMetadataAnnotationProcessor` to include the
'defaultValue' of a property when possible. For example the
'defaultValue' or 'server.port' is '8080'.
Default values are detected by inspecting the field assignments of
@ConfigurationProperties items. In order to detect field values some
internals of the Java compiler are used. To save a dependency on
'tools.jar' internal javac classes are accessed using reflection.
See gh-1001
Adds an annotation processor to generates a JSON meta-data file at
compile time from @ConfigurationProperties items. Each meta-data file
can include an array or 'properties' and 'groups'.
A 'property' is a single item that may appear in a Spring Boot
'application.properties' file with a given value. For example,
'server.port' and 'server.context-path' are properties. Each property
may optionally include 'type' and 'description' attributes to provide
the data type (e.g. `java.lang.Integer`, `java.lang.String`) and
some short documentation (taken from the field javadoc) about what the
property is for. For consistency, the type of a primitive is translated
to its wrapper counterpart, i.e. `boolean` becomes `java.lang.Boolean`.
A 'group' provides a higher level grouping of properties. For example
the 'server.port' and 'server.context-path' properties are in the
'server' group.
Both 'property' and 'group' items may additional have 'sourceType' and
'sourceMethod' attributes to indicate the source that contributed them.
Users may use `META-INF/additional-spring-configuration-metadata.json`
to manually provide additionally meta-data that is not covered by
@ConfigurationProperties objects. The contents of this file will be
read and merged with harvested items. The complete meta-data file is
finally written to `META-INF/spring-configuration-metadata.json`.
See gh-1001
Previously, the Gradle plugin’s ProjectLibraries produced a new library
for every file dependency, even if the dependencies where on the same
file. This would lead to a repackaging failure due to multiple
libraries having the same name.
This commit updates ProjectLibraries to treat file dependencies on the
same file as a single library, thereby resolving the name clash.
Fixes gh-1646
The fix for gh-1475 introduced the use of an artifact's group to
discriminate between two libraries with the same name (artifact id)
and version. However, in the case of Gradle, a group name was not
provided for libraries that have been resolved from a repository.
This commit updates ResolvedArtifactLibrary to use the group obtained
from the underlying ResolvedArtifact as its discriminator.
Fixes gh-1543
The applicationDefaultJvmArgs property was added in Gradle 1.7. This
commit updates RunPluginFeatures to access the property defensively
so that the plugin can be used with Gradle 1.6.
Fixes gh-1511
Prior to this commit, the repackage goal silently ignored the case of
two libraries having the same name and version but a different group.
As a result, the second library was overwriting the first one in the
repackaged jar.
This commit adds support for custom Library names and updates the
Maven and Gradle plugins so that the name includes the group ID
when there would otherwise be a duplicate.
Fixes gh-1475
This commit clarifies the role of the 'addResources' flag and makes
it explicit that any duplicate found in the target directory are
actually removed
Fixes gh-1479
This commit adds a 'skip' parameter to the 'repackage' goal that is
false by default. When this parameter is enabled, the repackage goal
does not run at all.
This can be used when repackaging should occur conditionally or
when a particular module in a hierarchy should not use this feature.
Fixes gh-1424
Previously, ProjectLibraries only considered a configuration's
direct file dependencies. This meant that a transitive file
dependency that should have been pulled in via a project dependency
was not included in the repackaged jar's lib directory.
ProjectLibraries has been updated to walk down the tree of project
dependencies and create libraries for any file dependencies that
are found.
Fixes gh-1368
* Windows: allow absolute file paths without file:/// prefix
* All: only add nested archives (not directories), so loader.path=lib/*
behaves the same as -classpath=lib/* (except for adding zip files)
Fixes gh-1352
The ExplodedArchive would erroneously always attempt to filter
its contents (and thereby shield them from a classloader that wrapped
it) even if they haven't been explicitly provided.
See gh-1352
Previously, Repackager would repackage a jar file as many times as
it was asked to do so. This lead to problems if a user made a mistake
when using Maven that led to the package phase being driven twice,
for example by running "mvn clean install package".
This commit updates Repackager so that a repackage call becomes a
no-op if the source jar's manifest already contains the
Spring-Boot-Version attribute which is added by repackaging.
Fixes#1251
Use Java 7 `registerAsParallelCapable` and `getClassLoadingLock` methods
when possible. This should improve performance when running on JDK 7+
whilst still remaining JDK 6 compatible.
Closes gh-1284
Before this change a property whose key was in a non-enumerable property source would
not resolve placeholders, leading to ${style} values in @ConfigurationProperties beans
even if the placeholders ere resolvable.
This commit refines the changes made under 4be688aa. 4be688aa made the
default jar task a special case which broke repackaging of the archive
produced by the default war task.
This commit refines RepackageTask’s logic so that, when it’s enabled,
it will repackage a jar task’s archive if:
- The jar task is equal to RepackageTask.withJarTask
- The name of the jar task is equal to RepackageTask.withJarTask
- RepackageTask.withJarTask is null, the jar task is not referenced
by another RepackageTask’s withJarTask, and the jar task has an
empty classifier
The last of these three is the default case and ensures the, when the
Spring Boot plugin is applied, default jar and war artifacts are
repackaged. The classifier check is required to prevent default source
and javadoc artifacts from being repackaged.
Fixes#1204
The logic that determined whether or not the repackaging action should
be applied to a particular jar task was broken and caused problems
when a custom RepackageTask was used in a project's build.
This commit updates the logic so that repackaging will be applied:
- To the default jar task if RepackageTask.withJarTask is null
- To a jar task if it is equal to RepackageTask.withJarTask
- To a jar task if its name is equal to RepackageTask.withJarTask
Repackaging is not applied if:
- RepackageTask.enabled is false
Numerous integration tests have been added to verify the repackaging
behaviour.
Fixes#1204
The new ResolvedArtifact-based minus implementation was checking the
wrong Set when deciding whether or not a ResolvedArtifact should
be included in the result. This was leading to provided dependencies,
that should have only been packaging in WEB-INF/lib-provided also
being packaged in WEB-INF/lib.
The WarPackaging tests have been updated. In addition to checking that
WEB-INF/lib-provided does not contain anything that’s unexpected, they
also verify the contents of WEB-INF/lib
Fixes#1187
Fix 'fat jar' support for windows to correctly deal with URL and path
slash issues. The root cause of the original problem was caused by JAR
URLs not including a root slash (ie `file:C:/Users` vs `file:/C:/Users`)
Fixes gh-1145
Update ExecutableArchiveLauncher so that `-cp` URLs are not added
when they are already contained as nested JARs. This prevents a
SecurityException "signer information does not match error" when using
signed jars. The root cause of the issue was that the primary JAR file
was on the default classpath with the URL "file:....jar" and in the
main URL set as "jar:file:....jar". It is now filtered so that only
the "jar:" variant is added.
Fixes gh-1134
Update the executable JAR code to automatically unpack any entries
which include an entry comment starting `UNPACK:` to the temp folder.
The existing Maven and Gradle plugins have been updated with new
configuration options and the `spring-boot-tools` project has been
updated to write the appropriate entry comment based on a flag passed
in via the `Library` class.
This support has been added to allow libraries such a JRuby (which
assumes that `jruby-complete.jar` is always accessible as file) to work
with Spring Boot executable jars.
Fixes gh-1070
Add a Library class update the LibraryCallback interface and
implementations to use it. This change is in preparation for
an addition `unpack` flag that will be required to allow the
automatic unpacking of certain nested jars.
See gh-1070
Update JarURLConnection to allow the resolution of items within a nested
jar, even if the jarFile passed to the connection is several levels up.
This prevent a connection from incorrectly resolving an entry against
the wrong jar file.
See gh-1070
Phillip Webb
Stephane Nicoll
Andy Wilkinson
Dave Syer
Tommy Ludwig
Christian Flamm
Spring Buildmaster
Johnny Lim
Jakub Narloch
Vladimir Tsanev
Christian Brunotte
Eric Bottard
Uwe Schaefer
Johannes Edmeier
Kirill Vlasov
Michitomo Nakahara
Robert Thornton
mnhock
吉田 尚弘
Pedro Vilaca
mrumpf
ZakarFin
Tommy Ludwig
Bruce Edge
Thomas Raehalme
Ilayaperumal Gopinathan
Martin Lippert
arghya88
Matt Benson
Johannes Stelzer
Daniel Young and Mathew Johnson
Lugi Cardito
Eddú Meléndez
Sylvère Richard
Kris De Volder
Domingo Suarez Torres
Michael Cramer
David Turanski
David Liu
Eric Dahl
Phillip Webb
Dave Syer
Stephane Nicoll
Andy Wilkinson