The bean ID for the ContentNegotiatingViewResolver is now
"viewResolver" (it is the *one*). The conditions have been changed
so that a user only has to define a bean of the same name to switch
it off.
Fixes gh-546
Before this change the PropertySources loaded from external config
files were just added to the list for resolution in the order that
they were loaded. That worked for simple cases, but when there are
profiles active, and files themselves can activate profiles, it led
to users not being able to change default settings easily (either
on command line or in files, mostly in files).
The solution proposed here is to group PropertySources by profile
and resolve them in order of profile first, and then in order of
the files being loaded.
There are additional shenanigans because the order of the files
being loaded also has to be carefully defined. The rule for users
is that in a list of files to load (e.g. if set via
spring.config.location), the last one wins (natural if you think of
it as a merge of multiple maps). In addition, anything specified
by a user takes precedence over the defaults (which was broken in
some scenarios before).
Additionally, fixes profile ordering in @ConfigurationProperties(path=...)
Fixes gh-483
The most natural order is "more specific locations win". That way
if a use has application.properties in the root of a JAR (as is
normal), overrides can always be made on
classpath:/config/application.properties (as well as
file:./application.properties which has always been the case).
Before this change properties in classpath:/config/* were over
written by those in the root location, not the other way round.
Fixes gh-527
This commit adds a documentation note explaining how to change
the delimiters used to filter maven tokens as these conflict with the
delimiters used by Spring (i.e. ${foo:default}).
Change the initial fix for OSX Java 1.6 compatibility by removing the
need for a direct `tools.jar` dependency.
It appears that `system` dependencies are always pulled in when
used in a Maven plugin. This makes the the dependency on `tools.jar`
particularly brittle since we need to make assumptions about where
the jar is located.
Since the tools jar is *only* needed for Spring Loaded support, the
plugin has now been updated to locate the jar programmatically and
call it via reflection. This should reduce the risk of problems when
using the plugin and at the very least isolate them to Spring Loaded
support.
(See original commit b8c4720)
Fixes gh-497
Nicholas Hagen
hoserdude
Dave Syer
Spring Buildmaster
Phillip Webb
brockwmills
Christian Dupuis
Chris Savory
Andy Wilkinson
Stephane Nicoll
Piotr Maj