Previously, BeanDefinitionLoader declared a field of type
GroovyBeanDefinitionReader which is a GroovyObject subclass. This is
problematic as BeanDefinitionLoader is always loaded but Groovy is an
optional dependency. Even on a JVM where class verification is performed
lazily, this can still cause problems if something reflectively tries
to access the class’s declared fields. On a JVM where classes are
verified at load time, it would be impossible to start a Spring Boot
application without having Groovy on the classpath.
This commit changes the field to be a BeanDefinitionReader, removing
the indirect reference to GroovyObject form BeanDefinitionLoader’s
signature. The reader is downcast to a GroovyBeanDefinitionReader in the
body of a method body that will only be invoked when Groovy is on the
classpath.
Closes gh-5040
Update SpringBootJoranConfiguratorTests to ensure that logback
is left in a sane state. Prior to this commit, running all tests
in eclipse would fail due to ErrorPageFilterTests expecting
specific log output.
Spring Boot fires event very early in the application lifecycle and we
should make crystal clear that a regular `@Bean` registration cannot be
used to register a listener on them.
Closes gh-5061
This commit enables the use of // @formatter:off and // @formatter:on
to surround lines of code that should not be formatted. It also adds
a code template that can be used to quickly wrap the selected lines
of text with the off and on comments.
Closes gh-5050
Update the ContextIdApplicationContextInitializer default NAME_PATTERN
to favor the developer defined `${spring.application.name}` value over
the deployer defined `${vcap.application.name}`.
Fixes gh-4926
Update TomcatEmbeddedServletContainerFactory so that logic to disable
persistent sessions happens after Tomcat's standard Manager creation
logic.
Fixes gh-4543
Update `ResourceBundleCondition` to only enable the messages source
if `messages.properties` (and not `messages*.properties`) exists. This
operation is much faster that performing a pattern match since a full
jar entry scan is not required.
Since adding `messages.properties` is good practice and this change
allows us to delete the custom `PathMatchingResourcePatternResolver`
it seems like a fine compromise to make.
Fixes gh-4930
See gh-4811
Commit 5a1ee6eb added support for disabling use of start-stop-daemon
via a placeholder in the default launch script. Unfortunately, that
placeholder was subsequently broken in 81a47639.
This commit reinstates the placeholder and adds tests to verify that all
of the placeholders in the launch script can be replaced and that they
have the required default values. Furthermore, it also allows the use of
start-stop-daemon to be configured via USE_START_STOP_DAEMON in an
app’s .conf file. This allows the configuration to be changed after the
app has been built.
Closes gh-4985
When a Jersey app is deployed to a standalone container, Jersey’s
ServletContainerInitializer will run and register a servlet for a class
annotated with @ApplicationPath. If Jersey’s ServletContainerInitializer
runs before Spring’s, this servlet will take precedence over the
servlet registered by JerseyAutoConfiguration and will therefore not be
configured with any init parameters specified using spring.jersey.init
For the case where Jersey’s SCI runs first, this commit updates
JerseyAutoConfiguration to examine the servlet context for an existing
registration of Jersey’s servlet (Jersey names the registration using
the fully-qualified name of the ResourceConfig subclass). If a
registration is found its init parameters are configured using the
configuration provided by spring.jersey.init.
For the case where Spring’s SCI runs first, this commit updates
JerseyAutoConfiguration so that it names its registration using the
fully-qualified name of the ResourceConfig sub-class. This allows
Jersey’s SCI to find the existing registration rather than attempting
to configure its own.
Closes gh-2471
If application context refresh fails, SpringApplication will have a
null context. Previously, this would result in an NPE when looking for
an ExitCodeExceptionMapper.
This commit updates SpringApplication to gracefully handle the context
being null when looking for an ExitCodeExceptionMapper.
Closes gh-4803
Previously, if an application’s main method threw an exception,
MainMethodRunner would catch the exception and call System.exit(1).
This meant that the JVM would exit, irrespective of whether or not
any non-daemon threads were running. In contrast, when an application’s
main method was invoked directly (in an IDE, for example) the JVM
would not exit if one or more non-daemon threads were running. This
is standard JVM behaviour that we should be consistent with in the
launcher.
This commit updates MainMethodRunner to wrap any exception thrown by an
application’s main method in a RuntimeException and rethrow it. This
alllows the JVM to handle the exception and use its normal rules for
deciding whether or not it should exit.
Closes gh-4984
While Flyway's `MigrationVersion` is a String value, a simple "0" is
also a valid number. When such value is not wrapped in YAML, an integer
is injected rather than a String which leads to a failure as we can't
convert it.
This commit updates the `StringToMigrationVersionConverter` to also
supports conversion from a Number. This is a convenience for users
using YAML for configuration
Closes gh-4981
This commit makes sure to also include any `GenericConverter` flagged for
inclusion in the conversion service to use to convert configuration keys.
Previously, those were ignored as `Converter` and `GenericConverter` are
two separate interfaces.
Closes gh-4988
The same initializer will receive multiple ContextRefreshedEvents
when their is an application context hierarchy. This commit updates
the initializer to correctly handle multiple ContextRefreshedEvents
and only act upon the first that it receives.
See gh-4871
This commit is a continuation of the changes made in b85b608. It
addresses an additional problem when testing applications where two
contexts are refreshed in quick succession. In this scenario, it
was possible, theoretically at least, for the first context’s background preinitialization to still be in progress and creating loggers when the
second is refreshed and resets the logger context.
This commit updates BackgroundPreinitializer so that, upon receipt of
a ContextRefreshedEvent, it waits for preinitialization to have
completed. In the scenario described above, this ensures that
preinitialization has completed before the call to refresh() for the
first context returns, thereby preventing it from running in parallel
with the refresh of the second context.
Closes gh-4871
If Both Hazelcast and Hibernate are available, Spring Boot takes the
opinion that Hazelcast can be used for 2nd level caching and therefore
need to start before Hibernate.
Unfortunately, some users require Hibernate in some of their hazelcast
use case so the link is actually reversed. One way for such user is to
disable the auto-configuration that deals with this link. This class is
now public so that users can locate them and exclude them if necessary.
Closes gh-4960
Andy Wilkinson
Phillip Webb
Karol Rynio
Stephane Nicoll
Vedran Pavic
Johnny Lim
Spring Buildmaster
Jacques-Etienne Beaudet
Matt Benson
Robert Kapala