While this is a breaking change, continuing with Spring Social
Facebook 1.1.x is also broken as it is no longer compatible with
Facebook's API. Upgrading to 2.0.1.RELEASE may require some changes
to be made to users' applications, but it will allow their
applications to use the Facebook API once again.
Closes gh-2837
GemFire 8.0 depends on two different versions of xml-apis:xml-apis and
org.eclipse.jdt.core.compiler:ecj. This commit adds dependency
management for those two dependencies to address the dependency
convergence errors reported by Maven’s enforcer plugin.
GemFire 8.0 also depends on commons-logging and Spring Boot starters
should use jcl-over-slf4j instead. This commit adds an exclusion for
commons-logging
GemFire 8.0 depends (optionally) on spring-data-gemfire and
spring-data-gemfire depends on GemFire, i.e. there’s a dependency cycle
between the two projects. This commit breaks this cycle by adding an
exclusion for spring-data-gemfire to the dependency management for
com.gemstone.gemfire:gemfire.
This commit should be reverted once the problems with GemFire’s
dependencies have been addressed. See gh-2884.
Hibernate depends on antlr:antlr:2.7.7 (the latest version on Antlr 2)
and fails with earlier 2.7.x versions due to a missing method. This
can cause problems for Maven users if they also depend on something that
pulls in an earlier version of Antlr, such as
spring-boot-starter-velocity. Gradle users are unaffected as, when
multiple versions of a dependency are found in the graph, Gradle will
choose the latest version.
This commit adds dependency management for antlr:antlr:2.7.7 to ensure
that the latest, and Hibernate compatible, version of Antlr 2 is used.
Closes gh-2814
This commit updates Spring Boot to use Spring Security 4. As a result
of this, the coordinates of Thmyeleaf's Spring Security extra, for
which dependency management and auto-configuration is provided, have
been updated to the Spring Security 4 variant.
Closes gh-2727
The versions in the dependency management for the various datastore
dependencies have been aligned with those used by Spring Data Fowler.
The Data REST tests and sample application has been updated to configure
the base path in favour of the deprecated base uri property
Closes gh-2673
- Nest the configuration class in HealthIndicatorAutoConfiguration,
bringing it into line with the other health indicator configuration
classes
- Include the statistics from the response in the health’s details
- Map YELLOW to UP rather than UNKNOWN as it indicates that the cluster
is running but that “the primary shard is allocated but replicas are
not” [1]. The details can be used to determine the precise state of
the cluster.
- Add a property to configure the time that the health indicator will
wait to receive a response from the cluster
- Document the configuration properties
- Update the tests to cover the updated functionality
See gh-2399
[1] http://www.elastic.co/guide/en/elasticsearch/reference/1.x/cluster-health.html
Previously, the only starter that provided validation was
spring-boot-starter-web which included Hibernate Validator and
Tomcat's EL implementation. This left users writing non-web
applications to figure out the dependencies for themselves. They would
sometimes run into difficulties as Hibernate Validator's need for an
EL implementation would trip them up.
This commit adds a new starter, spring-boot-starter-validation,
which provides both Hibernate Validator and Tomcat's EL
implementation. spring-boot-starter-web has been updated to depend on
this starter rather than depending on Hibernate Validator directly.
Closes gh-2678
Include auto-configuration support for EhCache with auto-detection of
the default `ehcache.xml` at the root of the classpath. EhCache
configuration can also be set via `spring.cache.config`.
See gh-2633
Add support for cache manager auto-configuration that is triggered when
the `EnableCaching` annotation is added to a Spring Boot application.
A new "spring.cache" set of configuration keys is also provided. The
"spring.cache.mode" allows the user to specify the cache provider that
should be auto-configured. If no explicit configuration is provided,
the environment is checked for the best suited cache implementation,
that is:
- Generic if at least one `Cache` bean is defined in the context.
- Hazelcast if either a default configuration file is present or the
`spring.cache.config` property is set.
- JCache if one JSR-107 provider is present
- Redis if a `RedisTemplate` is defined in the context
- Guava
- Simple as a fallback option, using concurrent maps
- NoOp (that is, no cache) if the mode is set to "none"
If the provider supports it, it is possible to specify the caches
to create on startup via `spring.cache.cache-names`. If the provider
relies on a configuration file and a custom one needs to be used
`spring.cache.config` can be set to such custom resource.
If more than one JSR-107 provider is present, it is possible to force
the provider to use by setting the mode to `jcache` and specifying the
fully qualified class name of the CachingProvider to use via
`spring.cache.jcache.provider`.
See gh-2633
Andy Wilkinson
Craig Walls
pasali
izeye
Phillip Webb
Dave Syer
Spring Buildmaster
Stephane Nicoll
Eddú Meléndez