Before this change if no profile is active yaml documents with
spring.profiles=default were loaded, but they are also loaded
if there *is* an active profile which is more of a problem. In
addition if the user chanes the default profile in the
Environmemt Spring Boot ignore that value ("default" is a magic
String).
After this change:
* If no profile is explicitly active, the default profiles from
the Environment are used explicitly
* The default profiles cause properties to be loaded just like
other profiles, so from YAML documents with spring.profiles and
from files in application-default.properties for instance
* The default profiles are not active when any other profile is
* Properties defined in "top-level" YAML documents with no
specific spring.profiles still act as defaults for *all* profiles
Fixes gh-1219, fixes gh-2623
Spring Framework 4.2 introduces first-class support for explicit
annotation attribute overrides via a new @AliasFor annotation.
In order to avoid potential naming conflicts in the future and to make
the current, implicit attribute overrides explicit (as well as
documented), this commit retrofits @SpringApplicationConfiguration with
@AliasFor.
Closes gh-3400
Closes gh-3401
If spring-hateoas is on the classpath and an MvcEndpoint returns a
@ResponseBody it will be extended and wrapped into a Resource with links.
All the existing endpoints that return sensible JSON data can be extended
this way (i.e. not /logfile). The HAL browser will also be added as an
endpoint if available on the classpath. Finally, asciidocs for the
Actuator endpoints are available as a separate jar file, which if
included in an app will also generate a new (HTTP) endpoint.
Fixes gh-1390
The order of property values is only preserved if we check carefully
that each property is actually present in the source being inspected.
Fixes gh-3385
Update RelaxedDataBinder to so that property ordering is respected even
if relaxed names are used. Prior to this commit a System property named
`FOO_BAR` would never get bound to a `fooBar` field if `foo-bar` was
defined in application.properties.
Fixes gh-3385
If a JtaTransactionManager is present, it is associated with the
auto-created JmsListenerContainerFactory. However, if no such transaction
manager is present, local transaction support is not enabled.
This gives a default situation where the message is acknowledged even
before the listener is invoked. We now make sure to turn on local JMS
transactions if no JtaTransactionManager is present.
Fixes gh-3393
Previously, JacksonHttpMessageConvertersConfiguration would configure a
general-purpose MappingJackson2HttpMessageConverter only if there was
no existing MappingJackson2HttpMessageConverter in the application
context. This was problematic when a
TypeConstrainedMappingJackson2HttpMessageConverter bean was present.
Such a bean is only capable of performing conversion for a specific
type, and therefore is no substitute for a general purpose converter,
yet its presence was causing the auto-configuration of a general
purpose converters to be turned off. This would leave Spring MVC’s
default converter being used for application/json requests which would
not honour the user’s Jackson configuration.
This commit enhances @ConditionalOnMissingBean so that the annotation
can be used to specify one or more types that should be ignored when
searching for beans. This allows the
TypeConstrainedMappingJackson2HttpMessageConverter beans that are
published by Spring Data REST to be ignored such that the
general-purpose MappingJackson2HttpMessageConverter is still
auto-configured.
Fixes gh-2914
Update MustacheViewResolver so that buildView() is called to create
the MustacheView. This sets fields such as `contentType` and allows us
to remove explicit setApplicationContext() and setServletContext()
calls.
Fixes gh-3265
Dave Syer
Stephane Nicoll
izeye
Sam Brannen
Phillip Webb
Spring Buildmaster
sopov.ivan
Andy Wilkinson