This is an alternative to the fix made in 3b52909 which removed the
chown call entirely.
Prior to 3b52909, the ownership of $PID_FOLDER was always changed even
when its value was /var/run. This was problematic as it could prevent
other services from creating their pid folder or file.
When a sub-folder is used, changing its ownership so that it’s owned by
the user that will run the app is desirable as it limits access to the
folder. Rather than removing the chown call entirely, this commit
ensures that it only happens when a sub-folder is being used to hold the
pid file.
Closes gh-6532
Update the launch script so that it no longer changes ownership of the
PID_FOLDER.
Commit b24e736cfed77be5902f30b79548f051e91d56c9 had changed the chown
line from:
chown "$run_user" "$PID_FOLDER/${identity}"
to:
chown "$run_user" "$PID_FOLDER"
This meant that it was possible for the launch script to change
ownership of `/var/run` and prevent later processes from writing to
the folder.
Since PID_FOLDER is created before the chown statement, and that
the `checkPermissions` function runs to ensure that the PID file can
be written, it appears that the chown is not even required.
Fixes gh-6532
This commit improves the run goal to automatically fork the process when
devtools is present and log a warning when fork has been disabled via
configuration since devtools will not work on a non-forked process.
We don't want devtools to kick in for integration tests so the logic has
been placed in `RunMojo` requiring a couple of protected methods to
override.
Closes gh-5137
So far, one has to set the "fork" value to both the start and stop
goals. Since they have the same name, sharing them in a global
configuration element does the trick. However, the plugin also supports
auto-detection of the fork value according to other parameters:
typically if an agent or jvm arguments are set, forking will be
automatically enabled. This is a problem since the stop goal is not aware
of that.
This commit transmits the value in a property attached to the
`MavenProject`. That way, the stop goal can retrieve that value and
apply the same defaults. This has the side effect that specifying the
fork value isn't necessary anymore.
Closes gh-6747
Previously, configuring the build-info goal in a pom would result in
Eclipse reporting an error for the pom as it didn’t know if/when to
execute the build-info goal.
This commit adds lifecycle mapping metadata so that the goal is executed
on incremental builds. This ensures that the contents of the generated
file are kept up-to-date, reflecting the latest build time, etc.
Closes gh-6723
Previously, RandomAccessDataFile used a semaphore and acquired it
interruptibly. This meant that an interrupted thread was unable to
access the file. Notably, this would prevent LaunchedURLClassLoader from
loading classes or resources on an interrupted thread.
The previous commit (937f857) updates RandomAccessDataFile to acquire
the semaphore uninterruptibly. This commit adds a test to
LaunchedURLClassLoader to verify that it can now load a resource from
an interrupted thread.
Closes gh-6683
Previously, if mvn spring-boot:run with a forked JVM was killed with
CTRL+C, the run would be considered unsuccessful. This commits updates
the run mojo to consider a forked JVM that exists with 130 (the exit
code produced when exiting due to SIGINT which is what CTRL+C sends) to
be successful.
Closes gh-6498
The unpack location is (largely) an implementation detail and the
Repackage Mojo was the only place where it was explicity documented.
Rather than updating the outdated location, this commit removes it
entirely to avoid encouraging people to rely on the location.
Closes gh-6624
META-INF/INDEX.LIST files are pointless in an executable jar and
moving application classes from the root of the jar to
BOOT-INF/classes breaks the index, resulting in an
InvalidJarIndexException being thrown.
This commit updates the Repackager to automatically remove a
META-INF/INDEX.LIST file from a jar file that is being repackaged.
Closes gh-6601
Where possible, code that previously synchronized on this (or on the
class in the case of static methods) has been updated to use an
internal monitor object instead. This allows the locking model that's
employed to be an implementation detail rather than part of the
class's API.
Classes that override a synchronized method continue to declare
the overriding method as synchronized. This ensures that locking
is consistent across the superclass and its subclass.
Closes gh-6262
Previously, if a property name had successive capital letters, the
generated meta-data would clean it in such a way it is defined as a
regular word. For instance a `myFOO` property would be written as
`my-foo` in the meta-data.
It turns out this decision is wrong as the binder has no way to compute
back the name of the property and therefore `my-foo` wouldn't bind to
`setMyFOO` as it should.
This commit updates the meta-data name generation algorithm to properly
identify such cases: `myFOO` now translates to `my-f-o-o`. While the
generated name is a bit ugly, it now provides a consistent binding
experience.
Closes gh-5330
This commit improves the performance of JarURLConnection. There are two
main changes:
Firstly, the way in which the spec is determined has been changed so
that it’s no longer necessary to create an absolute file. Instead,
the JarFile’s pathFromRoot is used to extract the spec from the URL
relative to the JarFile.
Secondly, the number of temporary Objects that are created has been
reduced, for example by tracking an index as we process a String
rather than creating a new substring for each iteration.
See gh-6215
JarURLConnection is very performance sensitive. The change in 3772d9f
meant that every JarURLConnection would create a FilePermission,
irrespective of whether it was actually used.
This commit updates JarURLConnection to create its FilePermission
lazily. When there is no security manager a permission will no longer
be created at all.
Closes gh-5411
See gh-6215
Previously, JarURLConnection assumed that that URL with which it was
created would contain the absolute path of the underlying jar file.
This meant that when it was created with a relative URL, it could fail
to find an entry or throw a StringIndexOutOfBoundsException.
This commit updates the logic for normalizing the input URL so that
both absolute and relative URLs are supported.
Closes gh-6109
This commit detects case where the same set of keys are exposed several
times and prevents the compilation to complete. Previously, duplicate
keys were silently added to the meta-data.
Closes gh-5939
In fact the folder was already created if the app is running as
a different user, but not if running as the current user, so it
was just a question of moving one line out of an if block.
Fixes gh-5986
Update TypeUtils to guard against the use of older Java versions.
Both `Collection` and `Map` type lookups now fallback to generic free
versions of the classes.
Prior to this commit using `xmlbeans-maven-plugin` in combination with
Spring Boot's annotation processor could result in
`IllegalArgumentException: Incorrect number of type arguments`.
Fixes gh-6122
Previously, Maven repositories definition was specified in a profile that
is active by default. It means that as soon as any profile is enabled by
the user, said profile is no longer enabled. This has the nasty
consequences of having copy/paste in several places to make sure our own
profiles still have the proper repositories definition.
This commit creates a single "repositories" profile that is always active
unless a given property is explicitely specified. This allows to remove
the duplication and make things more consistent.
Some Gradle-specific repositories were also hard-coded in two modules
without any profile at all, meaning they were polluting the build of
anybody using it. While the impacted modules are gradle specific, that
repository has been shared in the new "repositories" profile as well.
Closes gh-6031
Andy Wilkinson
Johnny Lim
Phillip Webb
hengyunabc
Stephane Nicoll
Spring Buildmaster
Dave Syer