Several libraries that Spring Boot supports depend on JBoss Logging but
they use a variety of versions. This means that the actual version of
JBoss Logging that will be used depends on your build system. Gradle
will pick the latest version that’s in the dependency graph, Maven
will pick the version that’s nearest the root of the graph and, if two
dependencies are equidistant, it’ll pick the version that’s pulled in
by the dependency listed first in the pom. In short, it’s very hard to
reason about the version of JBoss Logging that you’ll actually use at
runtime.
This commit adds dependency management for JBoss Logging so that a
consistent version is used, irrespective of your build system or
dependencies.
Closes gh-4185
jersey-spring3 has a transtive dependencies on HK2’s bean-validator
module that embeds JBoss Logging, Hibernate Validator, and Classmate
without repackaging them. This makes it impossible to control the
version of those three libraries that will be used without relying on
classpath ordering.
This commit excludes the bean-validator dependency from jersey-spring3.
The Jersey starter already depends on our Validation starter which
pulls in the proper, and controllable, version of the three
dependencies listed above so users of our starters will be unaffected.
Closes gh-4186
This commit adds dependency management for Cassandra Driver’s three
modules. The version is the latest maintenance release of the minor version that’s used by Spring Data Cassandra in the Spring Data Gosling release train.
Closes gh-4167
Prior to 8.0.28 Tomcat required the key store and trust store (if any)
to be available directly on the filesystem, i.e. classpath: resources
would not work. Tomcat 8.0.28 removed this limitation.
This commit updates to Tomcat 8.0.28, updates the tests to verify
the new Tomcat capability and removes the obsolete documentation of
the restriction.
Closes gh-4048
Liquibase 3.4.0 contains a bug that causes the initialization of its
ServiceLocator to pollute its map of loggers with a DefaultLogger for
the logger named "liquibase". Liquibase 3.4.1 contains a change that
improves the situation, but does not address is completely. Creating a
CustomResolverServiceLocator, as we do, still causes the map of
loggers to be polluted due to logging that's performed in
ClassLoaderResourceAccessor.getResourcesAsStream.
The commit address the problem by upgrading to Liquibase 3.4.1 and
adding the package containing our custom logger to the default service
locator before we register our custom service locator. This ensures
that the logging that's performed during the creation of our custom
service locator will still use our custom logger.
Closes gh-3470
Closes gh-3616
Typically, a Spring Boot maintenance release would not move to a new
minor version of a dependency. However there is a security
vulnerability in Groovy [1] and 2.4.4 is the only release which
contains a fix for it.
The commit upgrades to 2.4.4, thereby ensuring that users of Groovy
are not vulnerable by default. Users of Groovy whose applications are
not affected by the vulnerability may choose to downgrade back to
2.3.11 by overriding Spring Boot's dependency management.
Closes gh-3540
[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3253
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 a new `spring-boot-configuration-metadata` module that provides an
API to manipulate Spring Boot configuration meta-data. Can read meta-data
from arbitrary locations, though the standard
`META-INF/spring-configuration-metadata.json` location must be preferred.
Closes gh-1970
Hazelcast introduced a regression in their dependency management as of
3.5 which brings freemarker. This has unfortunate side effect in a Spring
Boot application since the freemarker auto-configuration kicks in for no
apparent reason when hazelcast is used.
An exclusion has been applied until the issue is fixed in hazelcast.
Closes gh-3418
If spring-hateoas is on the classpath and an MvcEndpoint returns a
@ResponseBody it will be extended and wrapped into a Resource with links.
All the existing endpoints that return sensible JSON data can be extended
this way (i.e. not /logfile). The HAL browser will also be added as an
endpoint if available on the classpath. Finally, asciidocs for the
Actuator endpoints are available as a separate jar file, which if
included in an app will also generate a new (HTTP) endpoint.
Fixes gh-1390
Previously, spring-boot required org.json:json to be on the compile
classpath, but it was only there by virtue of it being a transitive
dependency of another of spring-boot’s dependency. This commit makes
it clear that spring-boot has an (optional) dependency on org.json:json
by having an explicit dependency declaration for it. Additionally, the
name of the version property and the alphabetical ordering in
spring-boot-dependencies have been corrected.
Closes gh-3290
Update `spring-boot-dependencies` to exclude `commons-logging` from
`infinispan-spring4`. The version pulled in was very old and included
a transitive dependency to `servlet-api` 2.4.
Fixes gh-3291
Add auto-configuration support for Apache Artemis which was formed when
HornetQ was donated to the Apache Foundation. The majority of this code
is based on the HornetQ auto-configuration.
Fixes gh-3154
Closes gh-3246
This commit aligns our dependency management for GemFire with the
version used by the version of Spring Data GemFire that we currently
depend upon.
Previously, some dependency management that was added (see #2884) to
work around problems with GemFire 8.0’s dependencies; specifically it
depended on different versions of org.eclipse.jdt.core.compiler:ecj and
xml-apis:xml-apis. The different dependency versions appear to no
longer be a problem with 8.1 so this dependency management is now
redundant and has been removed.
Closes gh-3284
This commit adds support for automatically configuring Spring Session.
In a web application when both Spring Session and Spring Data Redis
are on the classpath, Spring Session's Redis Http Session support
will be auto-configured. The max inactive interval for Redis-backed
sessions can be configured via the environment using the existing
server.session-timeout property.
Closes gh-2318
* Automatically spin up Authorization Server and Resource Server
* Automatically configures method level security included OAuth2Expression handler
* Wrote extensive unit tests verifying default behavior as well as the auto-configuration backing off when custom Authorization/Resource servers are included
* Created org.springframework.boot.security.oauth2 subpackage to contain it
* Can also disable either resource of authorization server completely with a single property for each
* Print out the auto-generated secrets and other settings
* Added spring-boot-sample-secure-oauth2 to provide a sample that can be run and poked with curl as well as some automated tests.
* Make users ask for which servers to install by adding @Enable*
* User has to @EnableGlobalMethodSecurity instead of using properties files
Add Spring Security OAuth2 support to Spring Boot CLI
* Triggered from either @EnableAuthorizationServer or @EnableResourceServer
* Needs to have @EnableGlobalMethodSecurity to allow picking the annotation model.
* By default, comes with import support for @PreAuthorize, @PreFilter, @PostAuthorize, and @PostFilter via a single start import
* Also need import support for the enable annotations mentioned above.
* Added extra test case and sample (oauth2.groovy)
Users that wish to override the version of Hibernate need to override
the hibernate.version property, as it’s the one used when declaring the
dependency management for Hibernate’s modules, so the
hibernate-entitymanager.version property is of little value.
Closes gh-3004
Updated to the `EmbeddedCacheManager` interface and added support for
default cache configuration.
Added dependencies management for the JCache support with tests
Fixes gh-2906, see gh-2633
Include auto-configuration support for Infinispan. It is possible
to specify the caches to create via `spring.cache.cache-names`.
Provider also allow to set configuration file via `spring.cache.config`.
See gh-2633
Without dependency management for org.apache.httpcomponents:httpcore,
it’s possible to get mismatched versions of httpcore and httpclient.
Closes gh-2941
Previously, the CLI’s dependency management used proprietary Properties
file-based metadata to configure its dependency management. Since
spring-boot-gradle-plugin’s move to using the separate dependency
management plugin the CLI was the only user of this format.
This commit updates the CLI to use Maven boms to configure its
dependency management. By default it uses the spring-boot-dependencies
bom. This configuration can be augmented and overridden using the new
@DependencyManagementBom annotation which replaces @GrabMetadata.
Closes gh-2688
Closes gh-2439
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
This commit replaces Spring Boot's basic dependency management support
with separate dependency management plugin. This has a number of
benefits including:
1. A Maven bom can be used rather than a custom properties file
2. Dependency management is applied transitively rather than only to
direct dependencies
3. Exclusions are applied as they would be in Maven
4. Gradle-generated poms are automatically configured with the
appropriate dependency management
Closes gh-2133
By default, SnakeYAML will convert a timestamp-like string into a
java.util.Date. This differs to properties file-based configuration
where the values are always strings. Dates are problematic as the
round trip (string -> Date -> string) can change the value. For example,
“2015-01-27” becomes “Tue Jan 27 00:00:00 GMT 2015”.
This commit updates YamlPropertySourceLoader to use a Yaml with a
custom Resolver subclass that suppresses the addition of the implicit
resolver for timestamps. Supressing the addition of the unwanted
resolver, rather than overriding addImplicitResolvers and registering
the resolvers that we do want, ensures that we get all of the other
default Resolvers in their default order.
Fixes gh-2422
This commit adds support for configuring Log4j 2 with YAML. It also
improves the existing support for configuring Log4j 2 with JSON.
Previously, Log4J2LoggingSystem returned a hard-coded list of standard
config locations that includes both JSON and XML file suffixes. Log4j
2’s support for JSON configuration files requires Jackson’s ObjectMapper
to be on the classpath so, in its absence, the standard config locations
were incorrect.
This commit updates Log4J2LoggingSystem to return an array of standard
config locations based on what’s on the classpath. It also updates the
documentation to describe the additional dependencies that are required
to enable YAML or JSON-based configuration.
Closes gh-2239
Jetty’s GzipFilter is a container-agnostic Filter that can be used to
provide gzip and deflate encoding of HTTP responses. This commit adds
auto-configuration for GzipFilter that is enabled when
org.eclipse.jetty:jetty-servlets is on the classpath. The filter can
be configured using spring.http.gzip.*
See gh-2031
A dependency on org.glassfish.jersey.ext:jersey-bean-validation has
been added to spring-boot-starter-jersey. jersey-bean-validation’s EL
dependencies have been excluded in favour of those provided by
spring-boot-starter-tomcat (or starter-jetty or starter-undertow should
the user choose to use a different embedded container).
Closes gh-2315
The package names changed a bit from the prototype project, but wuth vanilla
autconfiguration usage that shouldn't matter. Follows closely the Groovy
templates support. Templates live in classpath:/templates/*.html by default.
Fixes gh-2242
Update spring-boot-dependencies to include all Jetty modules. The helps
to prevent issues when modules are pulled in transitively (for example
via solr).
Fixes gh-2180
Add auto-configuration for thymeleaf-extras-conditionalcomments which
allows parsing of conditional comments for IE.
Example:
<!--[if lt IE 8]>
<link rel="stylesheet" th:href="@{/styleIE.css}"
type="text/css"/>
<![endif]-->
Without this dialect all Thymeleaf attributes are ignored inside the
comment.
Fixes gh-2113
Mixing Hibernate and a JTA provider may lead to duplicate JTA
dependencies as the API is published with different coordinates.
The following has been applied:
* We now use `javax.transaction:javax.transaction-api` everywhere.
* The `data-jpa` starter has been updated to replace the JBoss JTA
dependency with the standard one.
* The `jta-bitronix` starter has been updated to use JTA 1.2 instead of
JTA 1.1 (unfortunately, JTA 1.1 is published with different
coordinates).
* The `jta-atomikos` starter has been updated to define a dependency on
JTA as the current version does not do it at all.
* The HornetQ JMS server is also relying on JTA but that dependency
should have been optional. It has been excluded for the time being as
it was using (yet) another set of coordinates.
Fixes gh-2092
Unlike the Tomcat and Jetty starters, the Undertow starter does not
provide an EL implementation. This leads to failures when you try to use
Hibernate Validator with the Undertow starter.
To bring the Undertow starter into line with the other two embedded
container starters, this commit adds Glassfish’s EL implementation to
the Undertow starter. This is the implementation that’s used by the
Jetty starter. If/when Undertow provides JSP support and, therefore,
starts using EL itself, we should align with it.
Closes gh-1979
Add a companion module that IDE developers can use to read configuration
metadata from multiple sources into a single repository.
ConfigurationMetadataRepository provides access to groups and items as
well as an harmonized view on "sources" (that is the POJOs that have
contributed to a given group).
Closes gh-1970
hibernate-jpamodelgen was requested by a Boot user. hibernate-ehcache
and hibernate-envers were requested by a Spring IO Platform user (see
spring-io/platform#11
Closes gh-1896
The exception message for a connection timeout has been updated to
include the timeout period. The tests for the sample have been updated
accordingly.
Closes gh-1884
Traditionally, a @ServerEndpoint-annotated bean is found by a servlet
container initialiser, however Boot does not run servlet container
initialisers when an embedded container is being used. To be able to use
@ServerEndpoint in a Boot app that uses embedded Tomcat a
ServerEndpointExporter bean must be declared.
This commit updates the documentation to describe this requirement and
also updates the WebSockets sample to illustrate the use of
ServerEndpointExporter. The version of Spring Framework has been updated
to 4.0.8.BUILD-SNAPSHOT. This picks up the fix for SPR-12340.
Closes gh-1722
This commit updates Spring Boot to Liquibase 3.3.0 and makes the
necessary changes to Boot's PackageScanClassResolver.
Previously, when a class found by the scan could not be loaded a
warning message was logged. This commit lowers these to debug level,
bringing them into line with logging that the standard Liquibase
implementation does. It also avoids a warning always being logged at
startup due to Liquibase's WatchCommand$DynamicContentHandler which
depends on Jetty (an optional dependency of Liquibase).
Closes gh-1382
Upgrade to latest versions of Tomcat and Jetty and to the latest Servlet
API whilst will remaining compatible with Tomcat 7 and Jetty 8.
Fixes gh-1832, gh-369
Adds an annotation processor to generates a JSON meta-data file at
compile time from @ConfigurationProperties items. Each meta-data file
can include an array or 'properties' and 'groups'.
A 'property' is a single item that may appear in a Spring Boot
'application.properties' file with a given value. For example,
'server.port' and 'server.context-path' are properties. Each property
may optionally include 'type' and 'description' attributes to provide
the data type (e.g. `java.lang.Integer`, `java.lang.String`) and
some short documentation (taken from the field javadoc) about what the
property is for. For consistency, the type of a primitive is translated
to its wrapper counterpart, i.e. `boolean` becomes `java.lang.Boolean`.
A 'group' provides a higher level grouping of properties. For example
the 'server.port' and 'server.context-path' properties are in the
'server' group.
Both 'property' and 'group' items may additional have 'sourceType' and
'sourceMethod' attributes to indicate the source that contributed them.
Users may use `META-INF/additional-spring-configuration-metadata.json`
to manually provide additionally meta-data that is not covered by
@ConfigurationProperties objects. The contents of this file will be
read and merged with harvested items. The complete meta-data file is
finally written to `META-INF/spring-configuration-metadata.json`.
See gh-1001
This commit adds a new command to the CLI that allows to initialize a new
project from the command line. It uses the Spring initializr service to
actually generate the project.
The command offers two main operations:
1. Listing the capabilities of the service (--list or -l). This basically
dumps the defaults of a given service and the list of dependencies and
project types it supports
2. Generating a project. By default, http://start.spring.io is used and
its configured defaults are applied. Running spring init would therefore
have the same effect as clicking the 'generate project' on the UI without
entering any extra information. No file is overwritten by default.
The generation can be customized with the following options:
* --boot-version (-bv) Spring Boot version the project should use
* --dependencies (-d) comma separated list of dependencies to add to the
generated project
* --java-version (-jv) Java version to use
* --packaging (-p) the packaging for the project (jar, war)
* --target the url of the service to use
The actual type of the project can be defined in several ways:
1. Using the --type (-t) option that identifies a type that is supported
by the service
2. A combination of --build and/or --format that can be used to uniquely
identify matching these tags. Build represents the build system to use
(e.g. maven or gradle) while --format defines the format of the generated
project.
The project is saved on disk with the name provided by the server through
the Content-Disposition header, if any. It is possible to force it with
the --output option. It is possible to overwrite existing files by adding
the --force (-f) flag.
The --extract (-x) option allows to extract the project instead of saving
the zip archive. By default, the project is extracted in the current
working directory but it is possible to specify an alternate directory
using the --output option.
Fixes gh-1751
Spring IO Platform already provides dependency management for JavaMail.
This commit updates Boot’s new JavaMail dependency management to align
with the Platform, thereby allowing the Platform to inherit Boot’s
dependency management instead of defining its own.
This commit adds a new starter to auto-configure a MailSender when the
necessary classes are present and when the property "spring.mail.host" is
set.
The auto-configuration also accepts any arbitrary properties that
JavaMail might need using the "spring.mail.properties" prefix.
Fixes gh-1760
Phillip Webb
Jean de Klerk
Vedran Pavic
Stephane Nicoll
Andy Wilkinson
Dave Syer
Tommy Ludwig
Huang YunKun
Spring Buildmaster
izeye
Gary Russell
Julien Dubois
Craig Andrews
Roy Clarkson
Henryk Konsek
Roy Clarkson
Onur Kağan Özcan
Andreas Ahlenstorf
Eddú Meléndez
dgomesbr
Mario A. Alvarez Garcia
Greg Turnquist
Davide Angelocola
Craig Walls
pasali
Maciej Walkowiak
Michael Cramer
Drummond
Chris Schaefer
Sebastien Deleuze
sopov.ivan
Nathan Voxland