Remove README files that have been since been migrated to the reference
documentation. Also updated remaining markdown files to asciidoctor to
save having a mix of different formats.
Fixed gh-503
User can switch the behaviour on and off with
spring.datasource.continueOnError:true|false. I decided
not to add an extra nested level of property resolution
because of the existing spring.datasource.schema
(and other properties relating to initialization) because
concision seemed like a good thing with those more common
settings.
Fixes gh-374
Restore the previous `spring.profiles.active` logic effectively
reverting commit 37069d9. This ensures that active profiles defined in
a higher `PropertySource` replace those lower down.
In addition, add support for a `+` prefix that can be used to indicate
that a profile should be added to the active set.
For example:
# application-prod.properties
spring.profiles.active=+proddb,+prodmq
Fixed gh-308, gh-309
If any of the sources has a @PropertySource annotation (or many)
then we can add those properties to the Environment. It's a nice
convenient way of specifying a custom external properties location
for an app.
One problem is that Spring will come along and parse the same
annotations later as part of the @Configuration parsing. The
user has pretty limited control over how that is done, and it
will never be done in a "natural" way for a Boot application
(which would prefer that the default application.properties
is applied *last*, whereas Spring will apply the @PropertySource
last).
To get round that problem we add the property sources with
a different name (key in the PropertySources in Environment),
prefixing named property sources with "boot.", and adding
others with a name that is the same as the resource location
(instead of its description, which is the default for
Spring).
Another problem is that Spring doesn't know about YAML, so
the user is currently restricted to using properties files
with this annotation.
You can contribute additional HttpMessageConverters
by simply adding beans of that type in a Spring Boot
context. If a bean you add is of a type that would have been included
by default anyway (like MappingJackson2HttpMessageConverter for JSON
conversions) then it will replace the default value. A convenience
bean is provided of type MessageConverters (always available if you
use the default MVC configuration) which has some useful methods to
access the default and user-enhanced message converters (useful, for
example if you want to manually inject them into a custom
RestTemplate).
There are also some convenient configuration shortcuts for Jackson2.
The smallest change that might work is to just add beans of type
Module to your context. They will be registered with the default
ObjectMapper and then injected into the default message
converter. In addition, if your context contains any beans of type
ObjectMapper then all of the Module beans will be registered with
all of the mappers.
Phillip Webb
Dave Syer