The problem fixed here is that the Loader keeps track of the profiles it
is going to look at for loading files, but ignores any that were already
active in the Environment if the listener is called initially with
spring.profiles.active not empty.
Closes gh-4261
Previously, the `PORTFILE` system property was not checked if the
`EmbeddedServerPortFileWriter` was created using the default constructor.
This had the effect to prevent overriding of the port file when this
listener is created without any file or via `META-INF/spring.factories`.
Closes gh-4254
Add a BeanFactoryPostProcessor to set PRESERVE_TARGET_CLASS_ATTRIBUTE
to true on all ErrorController bean definitions. Without this attribute
AOP advice on @Controllers causes ErrorController beans to be created
as JDK proxies (since they implement a single valid looking interface)
and therefore not get found by Spring MVC.
Fixes gh-4236
Update the import order settings to be a little more logical. Imports
should now be ordered:
java.*
javax.*
<others>
org.springframework.*
import static *
See gh-4234
Commit adf2c44b was an attempt to prevent HSQLDB from throwing an
exception when the JVM exits. This was achieved by disabling the
application context’s shutdown hook in the tests. This had the unwanted
side effect of causing tests’ application contexts not to be closed. The
reported symptom was that @Destroy methods were no longer being invoked.
We need a different solution to the problem.
The exception was:
Caused by: org.hsqldb.HsqlException: Database lock acquisition failure: attempt to connect while db opening /closing
at org.hsqldb.error.Error.error(Unknown Source)
at org.hsqldb.error.Error.error(Unknown Source)
at org.hsqldb.error.Error.error(Unknown Source)
at org.hsqldb.DatabaseManager.getDatabase(Unknown Source)
at org.hsqldb.DatabaseManager.newSession(Unknown Source)
... 23 common frames omitted
I originally thought this was due to a race between the application
context’s shutdown hook and HSQLDB’s shutdown hook, however HSQLDB
doesn’t use a shutdown hook. I believe that the problem is due to
an HSQLDB database being created with shutdown=true in its URL, similar
to the problem described here [1]. This will shut down the database when
the last connection to it is closed, however the shutdown will happen
asynchronously. If the JVM then runs the application context’s shutdown
hook, EmbeddedDatabaseFactory will attempt to connect to the database to
execute the SHUTDOWN command. This executes synchronously but will race
with the asynchronous shutdown that’s executing as a result of
shutdown=true in the JDBC url and the last connection to the database
being closed.
This commit reinstates the use of application context shutdown hooks in
the tests, and updates the documentation to recommend that, if a user
manually configures the URL for their embedded database, they do so
in such a way that the database doesn’t shutdown automatically, thereby
allowing the shutdown to be driven by application context close.
Closes gh-4208
[1] http://sourceforge.net/p/hsqldb/bugs/1400/
Update `UndertowEmbeddedServletContainerFactory` so that the
`ClassPathResourceManager` is no longer registered by default.
Prior to this commit the resource manager would be registered whenever
a valid document root could not be found. This had the effect of
exposing all classpath files.
Fixes gh-4015
Previously, EndpointWebMvcChildContextConfiguration would attempt to
create a /error endpoint, irrespective of whether or not the parent
had such an endpoint. If the endpoint was disabled in the parent this
would cause a failure due to the absence of an ErrorAttributes bean.
This commit updates EndpointWebMvcChildContextConfiguration to make
the creation of its /error endpoint conditional on the existence of
an ErrorAttributes bean.
Closes gh-4164
Prior to 8.0.28 Tomcat required the key store and trust store (if any)
to be available directly on the filesystem, i.e. classpath: resources
would not work. Tomcat 8.0.28 removed this limitation.
This commit updates to Tomcat 8.0.28, updates the tests to verify
the new Tomcat capability and removes the obsolete documentation of
the restriction.
Closes gh-4048
Previously, the parent context was only considered when the builder
was used to run the application. If the application was built using
the builder and then run using SpringApplication.run, the parent
context was not considered.
This commit updates the builder to consider the parent both when it's
used to run the application and when it's used to build the
application that will later be run via SpringApplication.run
Closes gh-4014
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
Update Eclipse settings to make use of a custom Spring formatter
implementation. Using a custom formatter allows us to fix a couple of
issues with the version that shipped with Eclipse Mars.1 (Eclipse bugs
The custom formatter also means that it is possible to use Groovy
Eclipse despite the fact that it has formatter regressions (see
https://github.com/groovy/groovy-eclipse/issues/142).
Fixes gh-4136
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
Prior to this commit, EmbeddedWebApplicationContext would perform its
close processing and then stop the embedded container. This could
lead to the closed context's dispatcher servlet handling an HTTP
request and refreshing the context again. This opened up two
possibilities that we need to avoid:
1. Another HTTP request could be received by the dispatcher servlet
while the context is still being refreshed. This could lead to the
context being used before its refreshed. I believe this could be
the cause of the current modification exception described in
gh-3239 and SPR-13123.
2. It can lead to a race during shutdown as the shutdown hook's
attempt to close the context races with the refresh initiated by
the HTTP request. This is possible as the shutdown hook bypasses
the sychronization on startupShutdownMonitor that would normally
prevent refresh and close from occurring in parallel. This race
can lead to a deadlock as described in gh-4130
Closes gh-4130
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
Update the samples and integration tests to use Java 8. There's no
specific reason to keep them on Java 6 and it helps keep Eclipse happy
if we upgrade.
Mirrors of archive.apache.org only mirror the latest release of each
project so, as new releases are made, builds using older versions will
break as the mirrors are updated.
This commit updates the Tomcat deployment test to use the main Apache
archive site. This should provide long-term access to Tomcat binaries,
improving build stability and ensuring that tagged builds are
repeatable.
Backport of 5f087e6444
Previously, MetricsFilter would treat async requests the same as
sync requests and would record their response status as soon as the
request had been processed by the filter chain. This would result in a
200 response being recorded and the actual response status produced by
the async processing being ignored. Furthermore, the time that was
recorded for the request would not include the time take for any async processing.
This commit updates MetricsFilter to check whether or not an async
request has been started before it records the metrics for the request.
In the event of an async request having been started no metrics are
recorded. Instead, the StopWatch is stored in a request attribute that
is then retrieved during the filtering of the request’s async
dispatch(es). Once the async processing has completed (isAsyncStarted()
returns false), the StopWatch is stopped, removed from the request’s
attributes and the metrics for the request are recorded.
Closes gh-4098
Dave Syer
Stephane Nicoll
Phillip Webb
Andy Wilkinson
zhanhb
Spring Buildmaster