As there is no way to copy all the converters of a `ConversionService` to
another, `RelaxedConversionService` uses a fallback `ConversionService`
when the user-provided one failed.
That fallback is taking care of converting `String` to `Enum` in a case
insensitive way but it has no registered converter to convert a comma
separated String to a collection of something.
Ironically, our current test suite has plenty of cases where we map a
`String` to a collection of enums and they all pass. This is because
the tests do not provide a custom `ConverterService` so we end up
immediately in the fallback scenario. Since no converter is able to
convert the String to a collection, the property editor support of the
binder takes care of that for us and try to convert each individual
value.
In a regular use case however, a `ConversionService` is provided and
fails to map the collection if the String value(s) don't have the exact
same case as the annotations they represent. Since the original
`ConversionService` has claimed it was able to convert a collection,
the raw `String` value is passed to the fallback converter and that one
fails to convert the raw String.
The fallback converter now registers the necessary converters to
convert collections. Additional tests have been added to test that in
a more explicit way.
Closes gh-4322
Previously it was possible to bind a bean to the root prefix by just
adding `@EnableConfigurationProperties` with the class of said bean.
This use case is misleading and prevents any meta-data to be generated
for that object since the annotation processor reacts on the presence of
the `@ConfigurationProperties` annotation.
If a class is included in the list of configuration properties bean to
create via the `@EnableConfigurationProperties` annotation we now make
sure that the `@configurationProperties` annotation is present on it.
Closes gh-3460
Previously, ConfigFileApplicationListener was listed in spring.factories
as both an EnvironmentPostProcessor and an ApplicationListener. This
was problematic as ConfigFileApplicationListener is stateful and listing
it twice lead to two separate instances with separate state.
This commit restore ConfigFileApplicationListener to only being an
ApplicationListener. The driving of EnvironmentPostProcessors that was
performed by EnvironmentPostProcessingApplicationListener is now
performed by ConfigFileApplicationListener which adds itself as an
EnvironmentPostProcessor. This ensures that there’s only a single
instance of ConfigFileApplicationListener, allowing its state to be
managed correctly.
Closes gh-4258
Previously, LoggingApplicationListener used %rEx as the default
exception conversion word. This would result in the nested causes
being logging in reverse order, i.e. the most deeply nested cause
would be logged first.
This commit updates the default to be %wEx and adds a test to verify
the default behaviour.
Closes gh-4247
Previously, if getValidDocumentRoot() returned null, only the embedded
Tomcat container would use a temporary directory. This left Jetty and
Undertow unable to provide a URL for the root of the servlet context,
i.e. servletContext.getResource("/") would return null.
This commit updates the embedded containers for Jetty and Undertow to
behave in the same way as Tomcat. A test has been added to verify that
all three containers can produce a non-null URL for the root of the
servlet context.
Closes gh-2878
Previously, OrderedRequestContextFilter was ordered such that it
ran after Spring Security's Filter. This meant that the request
context was unavailable to any Filters in Spring Security's Filter
chain. Specifically, this caused a failure when using @EnableOAuth2Sso
as OAuth2ClientAuthenticationProcessingFilter, which is added to
Spring Security's Filter chain would be unable to use the
request-scoped bean upon which it depends.
This commit updates the order of OrderedRequestContextFilter so that
the request context is set up before Spring Security's Filter runs.
The tests for SampleGitHubApplication have been updated to use
TestRestTemplate rather than MockMvc. This is necessary as the latter,
via ServletTestExecutionListener, automatically populates the request
context holder, masking the fact that the request context filter was
setting it up too late.
Closes gh-4270
Improve the initial PR to include a filtering of the profiles that were
already enabled via the `spring.profiles.active` property.
Also add more tests to prove that each profile is loaded only once
now.
Closes gh-4273
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
Replace the custom Base64Encoder class with Spring's Base64Utils which
since 4.2 can encode bytes using Java 8's encoder, commons-digest or
Java 6's JAX-B encoder.
Closes gh-4189
Effectively revert commit b396d0d2 to restore exception first logging
of exceptions for Logback and Log4j2.
This commit also introduces new extended versions of "whitespace"
padding exception loggers so that source jar information is still
included in the stacktrace.
Fixes gh-4247
Update WebMvcAutoConfiguration to use a RequestContextFilter instead of
a RequestContextListener.
Using a filter is required for some Spring Session operations (see
https://github.com/spring-projects/spring-session/issues/129).
This update also has the added benefit of allowing the Response to be
accessed from RequestContextHolder.getRequestAttributes() by casting it
to ServletRequestAttributes.
Fixes gh-2637
Logback documentation explains how to initialize the logging system and
namely how the `logback.configurationFile` system property can be used to
specify the configuration file to use.
Spring Boot has an abstraction on top of that. A user can define the
`logging.path` property regardless of the logging infrastructure it is
using.
Users following the logback documentation can be confused at first so
we're not logging a warning when we found out that the logback specific
property has been specified.
Closes gh-2382
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
Change `SpringBootServletInitializer` so that the logger is created
in `onStartup` rather than on class creation. The allows logging to
be initialized in an different WebApplicationInitializer.
Fixes gh-3704
Update TomcatEmbeddedServletContainerFactory so that session data isn't
serialized by default. Prior to this commit the SESSIONS.ser file would
either be written to `/tmp` or into `baseDir` (if one was set).
By not saving session data we align Tomcat with the other embedded
servlet containers and reduce the risk of sensitive information being
left in `/tmp`.
Fixes gh-4156
Update ConfigFileEnvironmentPostProcessor to load profile specific
sections for all previously processed profiles. Prior to this commit
multi-profile YAML files were only loaded from the root
`application.yml` file.
With the updated logic, an `application-test.yml` file containing the
following:
someTestProperty: xyz
---
spring:
profiles: profile1
specificProperty: one
Can have the profile sub-document loaded using:
-Dspring.profiles.active=test,profile1
Fixes gh-4132
