If the user provides a JobExplorer and a BatchConfigurer that
don't require a DataSource we can back off on configuring ours
(and anything else that needs a DataSource).
Fixes gh-561
If user sets a ResourceLoader on the SpringApplication, he might
reasonably expect that it would be used to read the config files.
This change ensures that it is (instead of just using the
DefaultResourceLoader).
We can't support (yet) embedded containers inside a deployed war (class
loader conflicts are inevitable, really). Until we figure out a way to
do it, we should just log a warning and advise the user to switch to
JMX for the actuator endpoints.
See gh-552
ErrorPageFilter is itself an EmbeddedServletContainerFactory
but it runs in a non-embedded container. Any component that assumes
the presence of an EmbeddedServletContainerFactory implies we are
running embedded is therefore invalid. WebSocketAutoConfiguration
had that problem.
Fixes gh-551
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
Dave Syer
Nicholas Hagen
hoserdude
Spring Buildmaster
Phillip Webb
brockwmills
Christian Dupuis
Chris Savory
Andy Wilkinson
Stephane Nicoll