Previously, there were two problems with servlet context initializer
beans that are a scoped proxy:
1. When there's no explicit registration bean the target of the scoped
proxy is registered rather than the proxy. This meant that the
proxy had no effect as it was being bypassed.
2. When there is an explicit registration bean, the registration is
performed twice: the faulty implicit registration described above
and explicit registration.
A fix (SPR-14816) has been made in Spring Framework so that we can
correctly determine the type of bean that will be produced by a
scoped proxy's factory bean. That change, coupled with the change in
this commit that ignored beans that are the target of a scoped proxy
addresses both of the problems described above. A single registration
is now performed and its the scoped proxy, rather than its target,
that is registered.
Closes gh-7150
Update `DevToolsPropertyDefaultsPostProcessor` so that property defaults
are only added at development time. Properties are now added only when
`Restarter` is initialize or remote devtools is enabled.
Fixes gh-7014
Update `ApplicationPidFileWriter` to support `ApplicationReadyEvent` in
addition to the already supported `ApplicationEnvironmentPreparedEvent`
and `ApplicationPreparedEvent` events.
Closes gh-7066
Fixes gh-7027
Update JpaBaseConfiguration so that the persistenceUnitRootLocation is
no longer detected. The update to gh-7003 means that we can now rely on
the standard detection mechanism.
Fixes gh-6983
See gh-6635
Previously, if Boot's JarURLConnection pointed to the root of a nested
entry, e.g. /BOOT-INF/classes, a call to getInputStream() would throw
an IOException. This behavior is reasonable for a URL that points
to the root of a normal jar as the jar itself is on the class path
anyway. However, for a nested jar it meant that a call to
ClassLoader.getResources("") would not include URLs for any nested
jars and directories (/BOOT-INF/classes and jars in /BOOT-INF/lib).
This is due to some logic in URLClassPath.Loader.findResource that
verifies a URL by opening a connection and calling getInputStream().
The result of missing URLs for the root of nested jars and directories
is that classpath scanning that scans from the root (not a good idea
for performance reasons, but something that we should support) would
not find entries in /BOOT-INF/classes or in jars in /BOOT-INF/lib.
This commit updates our JarURLConnection so that it no longer throws
an IOException when asked for an InputStream for the root of a nested
entry (directory or jar).
Fixes gh-7003
Spring Boot Actuator hypermedia support has been disabled by default via
c7c685f, but its documentation wasn't updated.
This commit updates the documentation related to the change.
See gh-7215
Previously, the algorithm that computes the String representation of a
class reference and a property type was shared. This lead to generic
information for group's `type` and `sourceType` property.
This commit separates that logic in two: `getQualifiedName` is now
responsible to generate a fully qualified class name while the existing
`getType` is solely responsible to generate a type representation for the
property. Only the latter has generic information.
Closes gh-7236
This commit restores the logic in Handler that was changed when
d20ac56a was merged, while leaving the structural improvements intact.
In addition to a couple of changes where a typo meant the wrong
variable was being referenced, some logic branches now return false
rather than called super. This realigns our Handler's behaviour with
that of the JDK's.
Some more tests have also been added to try to catch the problems that
were introduced during the merge.
Closes gh-7021
Previously our handler didn't override parseURL or sameFile which
resulted in behaviour that differed from that of the JDK's handler.
Crucially, this would result in our JarURLConnection being passed
a spec that didn't contain a "!/". A knock-on effect of this was
that the connection would point to the root of the jar rather than
the intended entry.
Closes gh-7021
ErrorPageFilter contained an optimisation for looking up the path
of an error page by exception type. For cases where there was no
mapping for the type of the exception that was thrown but there
was a mapping for one of its super classes, it was intended to
speed up the lookup. Unfortunately, there was a bug in the
implementation which meant that the optimisation had no effect.
Analysis with JMH reveals that for an Exception with a deep type
hierarchy, such as Spring Framework's UnsatisfiedDependencyException,
and an error page mapping for Exception, searching up the hierarchy
until a mapping is found takes 0.0000001s. With the same mapping,
a lookup for Exception takes 0.00000001s, i.e. it's 10x faster.
The optimisation, when correctly implemented, brings the time for
UnsatisfiedDependencyException down to 0.00000001s and into line
with a lookup for Exception. However, the amount of time involved is
so small compared to the overall time spent processing a request that
the added complexity of the optimisation is not justified.
Closes gh-7010
Every classes that's compiled by Kotlin is annotated with
kotlin.Metadata. The attributes of this annotation always differ so
if they are used in the cache key, context caching will effectively
be disabled.
This commit updates the key used by ImportsContextCustomizer to
ignore the kotlin.Metadata annotation. Additionally, to align with
with Java where annotations in java.lang.annotation are ignored,
annotations in kotlin.annotation are also ignored.
Closes gh-7101
Andy Wilkinson
Phillip Webb
Mike Youngstrom
Greg Potter
Stephane Nicoll
Johnny Lim
Vedran Pavic
Kazuki Shimizu
Ken Dombeck