Harmonize the configuration properties for Undertow to match the changes
made for gh-2491.
Move `spring.undertow.accessLog*` to `spring.undertow.accesslog.*`
Add `directory`, `prefix` and `suffix` properties to further customize
how access logs are configured on Tomcat. Relocate all properties to the
`server.tomcat.accesslog` namespace.
`server.tomcat.accessLogPattern` and `server.tomcat.accessLogEnabled` are
deprecated and replaced by `server.tomcat.accesslog.pattern` and
`server.tomcat.accesslog.enabled` respectively.
Closes gh-2491
Previously, only folders on the classpath would be watched and used
to trigger a restart/reload of the application. This commit adds a
new property spring.devtools.restart.additional-paths that can be
used to configure additional paths that should be watched for
changes. When a change occurs in one of those paths a restart or
reload will be triggered, depending on the full restart exclude
patterns configured via the existing spring.devtools.restart.exclude
property.
Closes gh-3469
Three conditions must be met for the console to be enabled:
- H2 is on the classpath
- The application is a web application
- spring.h2.console.enabled is set to true
If spring-boot-devtools is on the classpath, spring.h2.console.enabled
will be set to true automatically. Without the dev tools, the enabled
property will have to be set to true in application.properties.
By default, the console is available at /h2-console. This can be
configured via the spring.h2.console.path property. The value of this
property must begin with a '/'.
When Spring Security is on the classpath the console will be secured
based on the user's security.* configuration. When the console is
secured, CSRF protection is disabled and frame options is set to
SAMEORIGIN for its path. Both settings are required in order for the
console to function.
Closes gh-766
The `bootRun` gradle task or `spring-boot:run` maven goal can be used to
start a Spring Boot app with DevTools as long as forking is enabled. Add
an explicit note in the documentation to mention that.
Closes gh-3315
Add an auto-configuration that avoid a Spring Boot user to add
`@EnableConfigurationProperties` to its configuration to benefit from
that feature.
As our own auto-configurations are tested independently, such annotation
is still present to avoid a useless reference to this new
auto-configuration.
Closes gh-2457
Add `spring.autoconfigure.exclude` to control the list of
auto-configuration classes to exclude via configuration. Merge the
exclusions defined on the `@EnableAutoConfiguration` or
`@SpringBooApplication` if any.
Closes gh-2435
Add a "management.health.defaults.enabled" property that controls whether
the default health indicators are enabled. This allow to disable them all
by default and still enable individual ones using their respective
specific property.
Closes gh-2298
Currently, the default TemplateResolver had no specific order. Thymeleaf
handles that with a "always first" strategy (that can be confusing if
several TemplateResolver have a "null" order.
While it is a fine default (and changing it could lead to weird side
effects), it has to be changed as soon as another TemplateResolver bean
is defined in the project.
The `spring.thymeleaf.template-resolver-order` property has been added to
control the order of the default TemplateResolver.
Closes gh-3575
Allow to disable the auto-startup flag of the default JMS and RabbitMQ
containers. This effectively permit to disable automatic listening via
configuration.
Closes gh-3587
A RepositoryRestMvcConfiguration subclass provided by a user is
problematic in a Spring Boot application as it causes
RepositoryRestMvcConfiguration's bean declarations to be processed
before any auto-configuration runs.
One problem that this causes is that it switches off Boot's Jackson
auto-configuration due to RepositoryRestMvcConfiguration having
already declared multiple ObjectMapper beans. Unlike Boot's
auto-configured ObjectMapper, none of these ObjectMappers are marked
as @Primary. This then leads to wiring failures due to multiple
candidates being available.
To address this problem a new RepositoryRestConfigurer abstract has been
introduced in Spring Data Gosling. Its use is now strongly preferred
over subclassing RepositoryRestMvcConfiguration. Note that our own
RepositoryRestMvcConfiguration subclass remains. It is imported as part
of auto-configuration (avoiding the ordering problems described above),
and provides configuration properties binding for
RepositoryRestConfiguration. However, the Jackson ObjectMapper
configuration has been moved out into a new RepositoryRestConfigurer
implementation.
While SpringBootRepositoryRestMvcConfiguration remains, this commit
makes it package private to discourage users from subclassing it. While
this may break existing applications, it, coupled with the documentation
updates, will hopefully guide them toward using
RepositoryRestConfigurer.
Closes gh-3439
Previously, the Spring Boot Gradle plugin would always apply the
application plugin to a project. It then piggy-backed on the application
plugin’s mainClassName and applicationDefaultJvmArgs properties for the
configuration of the bootRun task.
This commit updates the Spring Boot Gradle plugin so that it no longer
applies the application plugin. If the user applies the application
plugin then its configuration will be used, but it’s a no longer
requirement.
Users who do not need the application plugin, but who were using the
mainClassName or applicationDefaultJvmArgs properties will need to
change their builds as a result of this change as those properties will
no longer exist. As before, the mainClassName can be configured on the
springBoot extension:
springBoot {
mainClassName 'com.example.YourApplication'
}
The applicationDefaultJvmArgs property can be used, but it must now be
declared with the project's ext block. For example:
ext {
applicationDefaultJvmArgs = [ '-Dcom.example.property=true' ]
}
Closes gh-2679
Update Tomcat, Jetty and Undertow to serialize session data when the
application is stopped and load it again when the application restarts.
Persistent session are opt-in; either by setting `persistentSession`
on the ConfigurableEmbeddedServletContainer or by using the property
`server.session.persistent=true`.
Fixes gh-2490
Previously, the prefix was spring.embedded-mongodb. This was
inconsistent with the prefixes for Artermis and HornetQ which are
spring.artemis.embedded and spring.hornetq.embedded respectively.
See gh-2002
Embedded MongoDB is now auto-configured when it is on the classpath.
The Mongo instance will listen on the port specified by the
spring.data.mongodb.port property. If this property has a value of
zero and randomly allocated port will be used. In such an event, the
MongoClient created by MongoAutoConfiguration will be automatically
configured to use the port that was allocated.
By default, MongoDB 2.6.10 will be used. This can be configured using
the spring.embedded-mongodb.version property. Mongo's sync delay
feature is enabled by default. This can be configured using the
spring.embedded-mongobd.features property.
Closes gh-2002
Add an explicit note about the need of Spring MVC for actuator HTTP
endpoints. Also explicitly mention Jersey since it can be a source of
confusion.
See gh-2025
Stephane Nicoll
Andy Wilkinson
izeye
Rob Winch
Phillip Webb
drumonii
Lucas Saldanha
Sebastien Deleuze