I preferred /etc/bash_completion.d (since it mirrors the actual
preferred deployment of the scripts on my OS). Maybe the MacBoys
have a different point of view? Anyway the docs now point to the
actual script location.
Fixes gh-651
A more thorough check is needed to avoid the false assumption
that the DataSource is embedded just because an embedded database
is on the classpath. You really have to try and look in the connection
metadata, so that's what we now do.
Fixes gh-621, fixes gh-373
Rename the RestTemplates to TestRestTemplate to help indicate that it's
primarily intended for testing. Also now extend RestTemplate to allow
direct use, rather than via factory methods.
Fixes gh-599
Users only have to add a normal `WebMvcConfigurer` to configure
their own features. Sometimes that's not clear enough (and it's
good to stress that `@EnableWebMvc` is the thing that switches
off the Boot configurtation.
Fixes gh-583
Removed this link "The websocket sample shows you how to do that in Maven." since the example no longer has properties that show how this is done. Dave Syer edited the section in a previous issue by adding the example to the POM ( https://github.com/spring-projects/spring-boot/issues/430 ) but it appears that the bad link was not removed.
Introduce an extra `server.tomcat.uri-encoding` property used to
configure the URI encoding for the embedded tomcat container.
Defaults to `UTF-8` instead of the usual tomcat default of `ISO-8859-1`.
Fixes gh-540
- Add link to Spring Security's Global Method Security Java Configuration
- Fix link to SecurityProperties
- Add link to SECURITY Common application properties
- Remove unnecessary @Order from SecurityConfiguration
- Change method signature for @Autowired AuthenticationManagerBuilder to
compile / match Spring docs
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
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}).
