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
Note: the fully-qualified references to @Configuration in some of the
test configuration classes are required to work around a bug in javac.
1.8.0_102 (and earlier). Without them, compilation fails as it cannot
resolve the symbol despite the import statement and the unqualified
references working elsewhere in the same source file.
Closes gh-7056
The output capture for the deprecation warning only appears to work
when the test is run in isolation. I can't figure out why that's the
case, particularly as we have another test class
(BootRunResourceTests) that uses OutputCapture and works reliably.
I'm cutting my loses and removing the use of OutputCapture and the
assertion that the warnings is logged.
See 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
The cache abstraction is a core feature of the Spring Framework. Basic
features such as `@EnableCaching` are therefore available by default with
no extra dependencies necessary.
However, the actual cache adapters for JCache, Ehcache 2.x, Caffeine and
Guava are located in a separated module, `spring-context-support`. Spring
Boot provides that artifact via the `spring-boot-starter-cache` starter.
It is quite easy to "only" add the cache library dependencies and forget
about this extra dependencies since `@EnableCaching` is available by
default. This commit clarifies the role of the starer in each section so
that it is more obvious. We're already explaining this at the beginning
of the section but it seems that's not enough.
Closes gh-7071