Existing apps get a NoSuchMethodError before this change because
they were compiled expecting a different signature for the
deprecated FilterRegistrationBean constructor.
The upgrade to Hibernate 5.2.0.Final has provide to be too
problematic to live with. It requires Java 8, is incompatible with
a number of other projects in the Hibernate ecosystem, and it's
unclear for how long it will be maintained. We'd previously used
Hibernate 5.1.0.Final but its maintenance is also unclear with
Hibernate 5.1.1.Final being more than 3 months overdue.
This commit drops back to Hibernate 5.0.9.Final. This has a few
advantages:
- It's Java 7 compatible
- It's had some time to mature and should be reasonably free of
regressions for those moving from 4.3.x
- It's used in both Wildfly and JBoss EAP so there's a fair chance
that it will continue to be maintained.
Closes gh-6198
When a custom management.port is used, the child context is configured
with an EmbeddedServletContainerFactory bean that has the same class
as the parent context’s EmbeddedServletContainerFactory bean. This
ensures that the child context uses the same type of embedded container
as its parent when there are multiple embedded containers on the
classpath. It also causes a failure when the custom
EmbeddedServletContainerFactory subclass cannot be instantiated, for
example because it’s an anonymous inner-class.
This commit improves the diagnostics so that we fail fast with an
information exception message when we detect that the embedded servlet
container factory bean’s class cannot be instantiated.
Closes gh-6193
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
Following the upgrade to Tomcat 8.5, Jetty became the only container
that sends a Server header by default. This commit updates the factory
for Jetty to disable the default Server header bringing it into line
with Tomcat and Undertow.
All three containers continue to support server.server-header which
can be used to configure a custom server header.
Closes gh-4730
This commit changes the default version of Tomcat to 8.5.3 while
also retaining support for Tomcat 8.0 and 7.0. The main difference
in 8.5 is that the ServerSocketFactory abstraction that allowed the
TrustStore and KeyStore to be configured programatically no longer
exists. This logic has been replaced with the use of a custom URL
protocol (springbootssl) that provides access to the key store and
trust store of an SslStoreProvider. In addition to working with 8.5,
this approach has the advantage of also working with 8.0 and 7.0.
Closes gh-6164
This commit adds `@AliasFor` meta-data to annotations that declare an
alias attribute.
`@ConditionalOnProperty` and `@AutoconfigureRestDocs` were not migrated
due to the use of `AnnotationMetadata#getAnnotationAttributes`.
Closes gh-5187
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
Previously, if the `contextPath` of the application wasn't the root, the
HAL browser could not initialize since the `entryPoint` was referring to
an invalid location.
This commit makes sure to take the `contextPath` into account.
Closes gh-5814
By default, Tomcat forces the generation of a session id during startup
to ensure that a SecureRandom instance has been initialized. When there
is a lack of entropy (as is often the case on a newly booted VPS, for
example) this can block for a long time (several minutes in some cases)
causing users to incorrectly believe that their application has hung
during startup. This is particularly problematic for applications that
don't use HTTP sessions as they are paying the startup cost for no
benefit.
This commit address the problem by configuring a custom
SessionIdGenerator that does not initialize itself during startup.
Instead, the initialization is now deferred until a request for a
session id is made.
Closes gh-6174
Previously, SimpleInMemoryRepository used a ConcurrentReferenceHashMap
to store its locks. The type of map will discard its entries when the
JVM comes under GC pressure. With the code in its previous form, this
could lead to a NullPointerException when the following occurred:
1. putIfAbsent returned null indicating that a new entry has been added
to the map
2. GC pressure caused the map to discard the new entry
3. get returned null as the entry has been discard
There are two problems with the existing code:
1. Its usage of a ConcurrentMap is incorrect. The correct usage is:
a. Call get to see if the map already contains a lock
b. If the lock is null, create a new one
c. Call putIfAbsent to add the new lock
d. If the return value is non-null, another thread has created the
lock and it should be used. If the return value is null, use the
new lock created in b.
2. Once the use of ConcurrentMap has been corrected, the fact that it is
a ConcurrentReferenceHashMap means that different threads could
access the same value using different locks. This would occur if one
thread has retrieved a lock from the map and is using it, while GC
causes the lock to be removed from the map. Another thread then
attempts to get the lock and, as GC pressure has remove it, a new
lock is created allowing concurrent access to the same value.
This commit updates the code to use the ConcurrentMap correctly and also
replaces the ConcurrentReferenceHashMap with a ConcurrentHashMap. This
means that the repository will now use slightly more memory but this is
outweighed by the benefits of thread-safe updates and no risk of an NPE.
Closes gh-6115
DevTools deliberately throws an uncaught exception on the main thread
as a safe way of causing it to stop processing. This exception is
caught and swallowed by an uncaught exception handler. Unfortunately,
this has the unwanted side-effect of causing the JVM to exit with 1
once all running threads are daemons.
Normally, this isn't a problem. Non-daemon threads, such as those
started by an embedded servlet container, will keep the JVM alive and
restarts of the application context will occur when the user makes to
their application. However, if the user adds DevTools to an
application that doesn't start any non-daemon threads, i.e. it starts,
runs, and then exits, it will exit with 1. This causes both
bootRun in Gradle and spring-boot:run in Maven to report that the
build has failed. While there's no benefit to using DevTools with an
application that behaves in this way, the side-effect of causing the
JVM to exit with 1 is unwanted.
This commit address the problem by updating the uncaught exception
handler to call System.exit(0) if the JVM is going to exit as a
result of the uncaught exception causing the main thread to die. In
other words, if the main thread was the only non-daemon thread, its
death as a result of the uncaught exception will now cause the JVM
to exit with 1 rather than 0. If there are other non-daemon threads
that will keep the JVM alive, the behaviour is unchanged.
Closes gh-5968
Andy Wilkinson
Dave Syer
Stephane Nicoll
Marcelo Romulo Fernandes
Phillip Webb
Brian Clozel
Johnny Lim
Artem Bilan