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
Andy Wilkinson
Phillip Webb
Stephane Nicoll
Eric Bottard
Uwe Schaefer
Spring Buildmaster
Johnny Lim
Johannes Edmeier
Kirill Vlasov
Michitomo Nakahara
Robert Thornton
mnhock
Vladimir Tsanev
吉田 尚弘
Pedro Vilaca
Dave Syer
mrumpf
ZakarFin
Tommy Ludwig
Bruce Edge
Thomas Raehalme
Ilayaperumal Gopinathan
Martin Lippert
arghya88