Thymeleaf 3.0 implements the Spring 5.0 view infrastructure for WebMVC
and the new WebFlux framework. This commit adds auto-configuration for
the WebFlux support.
In that process, the configuration property for `spring.thymeleaf` has
been changed to add `spring.thymeleaf.servlet` and
`spring.thymeleaf.reactive` for MVC/WebFlux specific properties.
Now that the `spring-boot-starter-thymeleaf` does not only support
Spring MVC, the transitive dependency on `spring-boot-starter-web` is
removed from it.
Fixes gh-8124
This commit moves the existing Spring MVC Mustache support to its own
`servlet` package and adds a new one under `reactive` for the WebFlux
web applications.
New `MustacheView` and `MustacheViewResolver` types resolve and render
Mustache views for WebFlux applications.
Since this templating engine is now supported by two flavors of Spring
web apps, the `spring-boot-starter-mustache` does not depend anymore on
the `spring-boot-starter-web` one: it's up to the developer to add the
relevant starter `web` or `webflux` to their application.
Fixes gh-8648
Add autoconfiguration to bootstrap MongoDB Reactive Streams driver
components, reactive Spring Data MongoDB and reactive repositories. Add
bean dependency processor for flapdoodle so embedded MongoDB instances
are configured before bootstraping the reactive MongoDB client.
Add Spring Data MongoDB Reactive starter with blocking and non-blocking
dependencies. MongoDB requires a separate driver that is used in the
`ReactiveMongoTemplate` while `MappingMongoConverter` (shared amongst
blocking/reactive Template API) requires the blocking driver to resolve
DBRefs.
See gh-8230
This commit raises the minimum supported version of Thymeleaf to
3.0.x. It also upgrades Spring Social to a version that is compatible
with Thymeleaf 3.
Closes gh-7450
Closes gh-6258
See gh-7885
Update Spring Integration metrics support since Spring Integration
`4.3.6`+ no longer needs `spring-integration-jmx` enable
`MessageChannel`, `MessageHandler` and `MessageSource` metrics.
- Add `IntegrationManagementConfiguration` conditional auto-configuration
to provide `@EnableIntegrationManagement` when JMX is `enabled` or there
is no `IntegrationManagementConfigurer.MANAGEMENT_CONFIGURER_NAME` bean.
By default this bean doesn't exist and you explicitly should declare it
(e.g. via `@EnableIntegrationManagement`) if you would like to collect
metrics. At the same time Spring Integration enables it when JMX
management is present (that is a purpose of that new
`IntegrationManagementConfiguration`)
- Change `SpringIntegrationMetricReader` to read metrics from the
`IntegrationManagementConfigurer`, not `IntegrationMBeanExporter`
- Change `PublicMetricsAutoConfiguration` to register
`IntegrationManagementConfigurer.MANAGEMENT_CONFIGURER_NAME` bean if
not present. Since we are here in `actuator`, therefore we are
interested in the metrics for SI as well.
- Since we don't need JMX for the metrics any more, remove SI-JMX
dependency from the `spring-boot-starter-integration`.
- Remove `IntegrationManagementConfiguration` modification from the
`integrationMbeanExporter()`, since that looks like mutation of an
external object, when end-user would prefer their own options.
Therefore we don't need `ObjectProvider<IntegrationManagementConfigurer>`, too
- Add missed `MessageSourceMetrics` gathering for the
`SpringIntegrationMetricReader`
Closes gh-7722
Brian Clozel
Phillip Webb
Stephane Nicoll
Eddú Meléndez
Craig Andrews
Spring Buildmaster
Andy Wilkinson
Vedran Pavic
Mark Paluch
Davin Kevin
Madhura Bhave
Lars Grefer
Sebastian Laskawiec
Artem Bilan