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
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
The JVM only allows URL.setURLStreamHandlerFactory to be called once.
This is problematic as the JSP support in embedded Tomcat and embedded
Jetty both call this method.
This commit uses reflection to null out URL’s factory field before and
after the embedded Jetty tests have run. This ensures that they can
run successfully if Tomcat has already installed its factory and that
Tomcat-related tests can also run afterwards.
See gh-5290
Update SpringApplicationBuilder so that properties of the form
`abc=d:e:f` are correctly parsed. Prior to this commit the `:` delimiter
would always be chosen over `=`, even if `=` occurred first.
Fixes gh-6121
Update BeanDefinitionLoader to support loading from package names that
do not contain dots.
Prior to this commit `new BeanDefinitionLoader(registry, "somepackage")`
would fail because "somepackage" exists and is a resource but does not
contain valid XML. Somewhat surprisingly the InputStream returned by
the resource actually contains the listing of files in the package.
Fixes gh-6126
Previously, if a list of ciphers were configured, the default excludes
were still applied. Prior to Jetty 9.3, there were no default exclude but
Jetty 9.3 introduced some and they override the includes.
This commit makes sure that the exclude ciphers are cleared if at least
one cipher is explicitly configured.
Closes gh-6041
Update the detection logic used in ApplicationHome to:
- Deal with `!/` elements in URLs so that `BOOT-INF/classes` packaging
works as expected.
- Use the `start-class` when no explicit source class is provided to
prevent accidentally picking a home next to a `spring-boot.jar` that
happens to be on the classpath.
- Ignore search logic when running from a unit test.
Fixes gh-6129
Spring Framework allows a custom `ApplicationEventMulticaster` bean to be
defined with a well-defined bean. If such bean is present, it is used
instead of the default implementation.
This commit fixes `EventPublishingRunListener` to properly honour such
arrangement. Rather than registering a `ApplicationEventMulticaster` to
transmit the application listeners from the `SpringBootApplication` it
now only uses an internal multicaster for early events (i.e. events that
are fired before the context is actually refreshed).
This has the positive effect of making sure that `ApplicationReadyEvent`
is fired to the proper multicaster.
Closes gh-6048
When Tomcat is starting up and JNDI is enabled, it binds the web app
class loader into its ContextBindings, thereby enabling JNDI lookups
on any thread that uses the web app class loader as its thread context
class loader. When Boot starts an application, the application context
is refreshed on the main thread which has the app class loader as its
TCCL. This meant that any JNDI lookups performed during refresh would
fail.
gh-2038 described this problem and a fix was made in ff99bb0. The
fix was to set the main thread's TCCL to be Tomcat's web app class
loader. This fixed the JNDI lookup problem, but it has become apparent
that it has caused other problems when testing an application.
The fix for gh-2038 sets the main thread's TCCL when embedded Tomcat
starts (during application context refresh) and then restores it when
embedded Tomcat stops (as a result of the application context being
closed). This causes problems during testing as, when application
context's are cached, the close is delayed. This means that the main
thread's TCCL isn't restored, causing subsequent tests to run with the
wrong TCCL.
This commit takes a different approach to fixing gh-2038. Rather than
changing the main thread's TCCL, it binds the app class loader into
Tomcat's ContextBindings, thereby enabling JNDI lookups from the main
thread. To avoid leaving a reference to the app class loader in
Tomcat's ContextBindings, it unbinds the app class loader at the end
of application context refresh. This narrows the scope of the fix so
that it only applies during application context refresh which is the
period in which JNDI lookups were problematic.
Note that the original fix could have been modified to restore the
TCCL once context refresh has completed rather than waiting for the
context to be closed. However, my feeling is that leaving the TCCL
unchanged and specifically addressing the JNDI problem by manipulating
the context bindings is a more precise, and hopefully safer,
solution.
Closes gh-6053
Previously, the name of a join table when using Hibernate 5 would
differ from those when using Hibernate 4 with the default
SpringNamingStrategy.
This commit introduces SpringImplicitNamingStrategy which customises the
name of join tables to match those produced by SpringNamingStrategy.
Closes gh-5880
Previously, the CONSOLE_LOG_PATTERN property would always be set as
a result of base.xml including defaults.xml. This made it hard to
override the CONSOLE_LOG_PATTERN as it required a copy and paste of
the configuration.
This commit updates defaults.xml so that CONSOLE_LOG_PATTERN is only
set if it has not already been set. This reduces the configuration to
customize the console log pattern to a handful of lines.
Closes gh-5632
Closes gh-5867