Switch the Tomcat 8 and Jetty 9 samples to Tomcat 7 and Jetty 8. Since
Tomcat 8 and Jetty 9 are now the default versions the previous samples
are no longer relevant, however, we do need integration tests to check
that we remain compatible with Tomcat 7 and Jetty 8.
See gh-1832
It *is* very useful to have filtering on by default, so that is now
the case (in spring-boot-starter-parent). Users can filter resources
by default by adding @*@ placeholders (so as not to clash with Spring
${} placeholders).
Fixes gh-1199
Prior to this commit LoggingSystem initialization would happen multiple
times. Once to configure "quiet" logging, and again to configure correct
settings once the Application was initialized. This could cause problems
if `logging.groovy` logback files were used.
The logging system is now only initialized once (when possible) by
following these steps:
- Standard logging initialization occurs via the actual logging
implementation used (e.g. logback will load a logback.xml file if it
exists)
- beforeInitization() is called to prevent early log output.
Implementations now either use a Filter or simply set the root logging
level.
- initialize() is called with an optional log configuration file (e.g
a custom logback.xml location) and an optional log output file (the
default is null indicating console only output).
The initialize() method will attempt to prevent double initialization
by checking if a standard configuration file exists. Double
initialization now only occurs in the following situations:
- The user has a standard configuration file (e.g. classpath:logback.xml)
but also specifies a logging.config property. Double initialization is
required since the specified configuration file supersedes the default.
- The user has a standard configuration file (e.g. classpath:logback.xml)
and specifies a logging.file property. Double initialization is
required since the standard configuration may use a ${LOG_FILE}
reference.
In addition this commit removes the `logging.console` option and now
assumes that logging either occurs only to console or to both the
console and a file. This restriction helps simplify the LoggingSystem
implementations. If file only logging is required a custom logback.xml
can be used.
Fixes gh-1091
See gh-1612, gh-1770
Then we can optionally find a non-anonymous principal if there
is one. If the user is anonymous then the health result is cached
up to endpoints.health.ttl (default 1000ms) to prevent a DOS attack.
Fixes gh-1353
Previously, there was a timing window where the output file had been
created but it was empty. This would cause the test to fail as the
output was read from the empty file and didn’t match the expected “Hello
World”.
This commit updates the test to only process the resources in the output
directory when all the resolved resources have a non-zero content
length. An @Before method has also been added to delete the output
produced by the test so that the outcome of the test isn’t affected by
files generated by previous runs.
Fixes gh-1735
Update FaviconConfiguration to allow favicon.ico files to be resolved
from static resource folders (/META-INF/resources, /resources, /static,
/public) in addition to the root classpath.
Fixes gh-1656
Previously, RepositoryRestMvcBootConfiguration was not annotated with
@Configuration. This meant that it was processed in lite mode.
Crucially, in lite mode, there’s no proxying so each call to the
config() @Bean method from within other @Bean methods resulted in the
creation of a new RepositoryRestConfiguration instance. Furthermore, as
each of these instances wasn’t a Spring bean the configuration
properties were not applied.
This commit updates RepositoryRestMvcBootConfiguration to annotate it
with @Configuration so that it’s no longer processed in lite mode. It
also updates the unit tests and the Spring Data REST sample to verify
that the baseUri can be configured using application.properties.
Fixes gh-1675
Jersey 2 has some Spring support built in but it's a bit awkward to
use in a Boot app, so autoconfiguration seems appropriate. The tests
and sample show how to use it, but the short story is that any
@Component can define JAX-RS endpoints via @GET etc.
There's a sample for Jersey 1 as well (pay careful attention to
the plugin configuration if you want to build an executable jar)
Fixes gh-1651
Without the @Param annotations, using either of the search URIs would
resulted in a 400 response and an error describing the lack of @Param
annotation.
See gh-1627
If the actuator endpoints are configured on a different port then there
are some settings in the main ServerProperties that we would like to
re-use (e.g. the access log). The easiest way to do that is to just
configure the management server using the same ServerProperties instance
and then overwrite the things that are different (and stored in
ManagementServerProperties).
Fixes gh-1581
There was too much state really in the old implementation of
AuthenticationManagerConfiguration, and it was leading occasionally
to null pointers when method A assumed that method B had already
been called and it hadn't. This change manages to concentrate all the
references to an AuthenticationManagerBuilder into a single method
call, removoing the need for storing it at all.
Fixes gh-1556
Phillip Webb
Dave Syer
Andy Wilkinson
Spring Buildmaster
Daniel Fullarton
matzschmanski
Manuel Doninger
bangsen.yin
Stéphane DERACO