URL.getContent() is shorthand for URL.openConnection().getContent().
It creates an InputStream that isn't explicitly closed. This means
that a file handle remains open until the URLConnection is garbage
collected. This can lead to the process exceeding the limit for open
files.
Previously, LaunchedURLClassLoader was using getConent() when
proactively defining a package for a class that is about to be loaded.
getContent() was used to access nested jar files to check if they
contained the package and, if so, to retrieve the jar's manifest.
In place of using getContent(), this commit uses JarURLConnection's
getJarFile() method which provides access to the JarFile without the
unwanted side-effect of opening an input stream.
Closes gh-7180
Previously, a relative PID folder was not handled correctly when
running stop, status, or force_reload. This meant that a service
could be started when configured to use a relative pid file, but
then could not be stopped.
The PID folder should be treated as relative to the service's jar
file. This commit updates stop, status, and force_reload to push the
jar file's directory so that this is now the case for those three
commands.
Closes gh-7092
This commit makes sure that a meta-data group exposed via a deprecated
`@Bean` method is deprecated as well. This also works if the class
in which the bean method is defined is itself deprecated.
Closes gh-7100
To be compatible with Gradle's plugin portal, plugins must have an
ID that uses a reverse domain name. This means that spring-boot is
not compatible.
This commit introduces a new ID, org.springframework.boot, and
deprecates the old ID.
Closes gh-6997
To be compatible with Gradle's plugin portal, plugins must have an
ID that uses a reverse domain name. This means that spring-boot is
not compatible.
This commit introduces a new ID, org.springframework.boot, and
deprecates the old ID.
Closes gh-6997
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 b24e736cfe 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