This commit introduces support for Jackson based XML serialization, using the
new MappingJackson2XmlHttpMessageConverter provided by Spring Framework
4.1. It is automatically activated when Jackson XML extension is detected on the
classpath.
Jackson2ObjectMapperBuilder is now used to create ObjectMapper and XmlMapper
instances with the following customized properties:
- MapperFeature.DEFAULT_VIEW_INCLUSION is disabled
- DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES is disabled
JodaModuleAutoConfiguration and Jsr310ModuleAutoConfiguration have been removed
since their behaviors are now handled directly by the ObjectMapper builder.
In addition to the existing @Bean of type ObjectMapper support, it is now
possible to customize Jackson based serialization properties by declaring
a @Bean of type Jackson2ObjectMapperBuilder.
Fixes gh-1237
Fixes gh-1580
Fixes gh-1644
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
The missing bean condition on the auto-configuration classes for
Elasticsearch, Jpa, Mongo and Solr repositories have been tightened to
look for ElasticsearchRepositoryFactoryBean, JapRepositoryFactoryBean,
MonoRepositoryFactoryBean, and SolrRepositoryFactoryBean respectively.
In Spring Data Evans, when there are multiple repository types on the
classpath, a strict mode is entered to prevent the different
repositories from trampling over each other. A side-effect of this is
that for the Mongo domain types in the tests to be discovered they
must be explicitly annotated with @Document.
Closes gh-1338
Add support classes for the Bitronix JTA library, including:
- A Spring friendly ConnectionFactoryBean and DataSourceBean with
support for setting a direct XA source.
- A PostProcessor to apply shutdown ordering automatically.
See gh-947
Add support classes for the Atomikos JTA library, including:
- A Spring friendly ConnectionFactoryBean and DataSourceBean.
- A PostProcessor to apply "depends-on" ordering automatically.
- A bindable properties class for type-safe configuration.
See gh-947
Updates to prevent the maven-invoker-plugin from downloading remote
snapshot jars. Possibly caused by the recent changes to the
spring-boot-dependencies POM.
See gh-1413
The Maven plugin version numbers are defined in the pluginManagement
of the spring-boot-dependencies pom.xml. Consequently, they can be
deleted in the spring-boot-starter-parent pom.xml to avoid version
conflicts and duplicated version management.
Enable if all of the following are true:
- spring-cloud is on the classpath
- There is no Cloud bean present
(usually done by extending AbstractCloudConfig)
- The "cloud" profile is active
Fixes gh-1302
Autoconfigure spring-cloud
The dependency is currently declared in Spring IO Platform from where
it can be removed once it's using a version of Boot that contains
this change. To make the migration of the dependency management from
the Platform to Boot seamless, the dependency is versioned using a
property with the same name as is currently used by the Platform:
javax-cache.version
Closes#1347
Due to a mistake in Spring Batch 3.0.0 it has been necessary to
introduce a breaking API change (the addition of
BatchConfigurer.getJobExplorer()) in the 3.0.1 release. This commit
updates Boot to use 3.0.1 and modifies the Batch auto-configuration
and associated tests to implement the new method.
Simplify the exclusion logic used in Gradle by implementing implicit
exclusions rather than trying to detect transitive excludes.
This commit reverts much of the code originally included to fix gh-1047
which adds far too much complexity to the build and still doesn't solve
the underlying issue.
Fixes gh-1103
- upgraded Spring WS to 2.2.0.RELEASE
- replaced default MVC DispatcherServlet with MessageDispatcherServlet
- migrated XML based config with nww Spring WS Java config
Fixes: gh-412
Update all starter POMs to remove commons-logging dependencies that are
not longer required when using the Spring Boot Gradle plugin.
Mainly reverts code from 196f92bd42
See gh-1047
Update spring-boot-versions to generate a dependency-tree file and
attach it as an artifact. The file is generated by creating a temporary
POM and calling the invoker plugin.
The spring-boot-versions POM now depends on all spring-boot-starter-*
POMs to ensure that they have been installed before the dependency
tree is processes.
See gh-1047
We now register the Jackson JodaTime module with Jackson ObjectMappers
if it is on the classpath. We also register the JSR-310 module if it's
on the classpath and the application is running Java 8 or better.
Extracted the Jackson specific configuration previously residing in
HttpMessageConvertersAutoConfiguration into a JacksonAutoConfiguration
class.
Added the Jackson JSR-310 module as a managed Boot dependency.
Gradle hasn’t different exclusion semantics to Maven. In Maven you can
exclude spring-core’s commons-logging dependency once and it’ll be
honoured even if you have multiple transitive routes to commons-logging
via spring-core. In Gradle you have to exclude commons-logging from
everything that has a transitive spring-core dependency. To make matters
worse this doesn’t only apply to dependencies and exclusions declared in
build.gradle but also to dependencies and exclusions declared in the pom
files of the artifacts that a Gradle build depends upon.
In short, to make our starters work as intended with Gradle, this commit
adds many, many exclusions for commons-logging. It also removes
commons-logging exclusions from spring-boot-dependencies’
<dependencyManagement> as they have no effect with Gradle and their
presence can cause us to miss required exclusions in a starter
Fixes#987
Update all relevant starter POMs to include a `spring-core` dependency
with an exclusion on `commons-logging`. This prevents `commons-logging`
and `jcl-over-slf4j` from both being on the classpath.
Also add enforcer rules to ensure that commons-logging doesn't sneak
back in, and that there is no dependency convergence. (some additional
libraries were required in spring-boot-dependencies)
Tested with a sample maven project as well as using the `spring jar`
command.
Fixes gh-985
Provide auto-configuration support for HornetQ JMS broker, along with
an additional starter POM.
The connection factory connects to a broker available on the local
machine by default. A configuration switch allows to enable an embedded
mode that starts HornetQ as part of the application.
In such a mode, the spring.hornetq.embedded.* properties provide
additional options to configure the embedded broker. In particular,
message persistence and data directory locations can be specified. It is
also possible to define the queue(s) and topic(s) to create on startup.
Fixes: gh-765
Restore the dependency on commons-logging (transitively via spring-core)
for spring-boot. This means that we are not tied directly to SLF4J, but
it is still an option that can be used via `jcl-over-slf4j`.
The `spring-boot-starter-parent` continues to replace `commons-logging`
with `jcl-over-slf4j`.
Fixes gh-981
Quartz is an optional dependency of spring-context-support so there's
no need to exclude it
This is a baby-step towards using the Spring Framework bom (#955)
Unify the versions used in integration tests launched by the
maven-invoker-plugin. Allows for already cached local copies to be
used, hopefully speeding up the build.
Registers required components in application context if not available to
set up environment for usage with Spring Data Solr. Will listen on
SolrServer and SolrRepositories for configuration.
By default an HttpSolrServer is registered unless a zkHost (zookeeper
host) is defined. In that case an instance of CloudSolrServer will be
created.
By default multicore support is enabled, creating instances of
SolrServer for each core defined via @SolrDocument.
Previously spring-boot-dependency-tools used spring-boot-tools as its
parent. This meant that it inherited spring-boot-parents' dependency
management that we did not want to expose to applications. The
solution to this was to generate the effective pom and then filter
out any thing that did not appear in spring-boot-dependencies' pom.
This filtering had to unwanted side-effect of breaking bom imports:
the effective pom would contain the dependency management from the
imported bom, but this would be filtered out as the entries didn't
appear in spring-boot-dependencies' pom.
This commit updates spring-boot-dependency-tools to use
spring-boot-dependencies as its parent. This means that its effective
pom contains the desired dependency management and nothing more,
allowing the filtering logic to be removed.
The use of Spring Security's bom has been reinstated as it will now
work as intended and versions for its modules will be available in the
CLI and via the Gradle plugin.
Closes#825Fixes#838
- Remove dependency management for projects that Boot does not have a
runtime dependency upon
- Provide dependency management for all of Spring Batch’s modules
Default suffix .tpl. If groovy-templates is on the classpath user
can now add templates and get them rendered and resolved in an MVC
app.
TODO: Macro helpers for message rendering etc.
See gh-878
Since ActiveMQ 5.8.0, the modules structure has been revisited and
activemq-core no longer exists. The activemq-broker is required to
create an embedded broker. Since Boot creates such broker by default
if ConnectionFactory is present, a condition has been added to do so
only when the necessary classes are present in the classpath.
The default embedded broker is now configured to disable message
persistence altogether as this requires an extra jar since 5.8.0, i.e.
activemq-kahadb-store.
Split the ActiveMQ auto configuration from the JmsTemplate auto
configuration so these are totally independent.
ActiveMQAutoConfiguration has been created to detect and configure
the ActiveMQ broker if necessary.
The brokerUrl parameter was ignored as long as the inMemory parameter
was true. The actual brokerUrl to use is now determined by the user
defined values of those parameters: if the brokerUrl is set, it is always
used. If no brokerUrl is set, the value of inMemory determines if an
embedded broker should be used (true) or a tcp connection to an
existing local broker (false).
JmsTemplateAutoConfiguration now creates a JmsTemplate only if a
ConnectionFactory is available.
Fixes gh-872, gh-882, gh-883
Temporarily remove the Spring Security BOM import as version numbers
for the imported projects don't automatically get resolved by the
gradle plugin.
See gh-838
Add an explicit dependency to `hamcrest-core` in the
`spring-boot-starter-test` POM. This prevents version 1.1 from
accidentally being pulled in via junit.
Fixes gh-810
Temporarily remove the spring-data release train BOM since it cannot
be resolved until it is published to maven central.
The previous solution of adding an additional repository has been
reverted as it will pollute POMS for users that inherit from the
spring-boot-starter-parent POM.
The transitive dependency org.neo4j:neo4j-cypher-dsl:2.0.1 isn't
available in Maven Central. This was leading to frequent build breaks
so we've decided to remove the Neo4J starter until all of its
dependencies can be resolved from Maven Central.
Fixes#797
All dependencies have recently moved to the spring-boot-dependencies
POM but that POM does not contain the repositories that are required to
download milestone artifacts.
This commit moves the default profile that is active by default at the
right place in the hierarchy so that it is applied there as well.
In addition to the upgrade to Dijkstra (#743) Spring HATEOAS has been
upgraded to 0.11.0 (#801) and Mongo's Java driver has been upgraded to
2.12.1 (#689). In both cases this is the same version as is used by
Dijkstra RC1.
The new version of Mongo's Java driver changes the exception that's
thrown when Mongo isn't running and a connection attempt fails. The
Mongo sample has been updated accordingly.
RepositoryRestMvcAutoConfiguration has been updated to be configured
before JpaRepositoriesAutoConfiguration. This ensures that the
former's transitive import of SpringDataJacksonConfiguration takes
precedence over the latter's import of the same. This is necessary as
RepositoryRestMvcConfiguration requires a bean that's declared by
SpringDataJacksonConfiguration and, if JpaRepositoriesAutoConfiguration
is processed first, its conditions may cause the import
SpringDataJacksonConfiguration to be skipped causing instantiation
of RepositoryRestMvcConfiguration to fail.
Closes#689Closes#743
Replace the `spring-boot.version` property with a hard-coded value,
rather than relying on the parent version. Allows locally installed
snapshots to be used as the parents of projects with a different version
number.
This commit harmonizes the dependency management of internal modules
so that versions can be omitted everywhere. Update the maven coordinates
to provide the full groupId for consistency
There are some issues with 3.1.1. Performance is one
(according to JIRA https://liquibase.jira.com/browse/CORE-1706),
but the biggest is that there is a package change for the main
ChangeLogHistoryService provider and it's package
(liquibase.channgelog) is not included in the service locator
scan by default. For some reason this only manifests itself
when using the SpringPackageScanClassResolver.
Fixes gh-687
Previously, spring-boot-dependencies listed a subset of Spring
Security's modules. This commit updates it to import Spring Security's
bom instead, thereby providing dependency management for every
module in Spring Security.
Closes#760
We still prefer Tomcat if it is available (that can change
if the community asks loudly enough). Hikari is supported
via the same spring.datasource.* properties as Tomcat (and
DBCP), with some modifications:
* The validation and timeout settings are not as fine-grained
in Hikari, so many of them will simply be ignored. The most
common options (url, username, password, driverClassName) all
work as expected.
* The Hikari team recommends using a vendor-specific DataSource
via spring.datasource.dataSourceClassName and supplying it with
Properties (spring.datasource.hikari.*).
Hikari prefers the JDBC4 isValid() API (encapsulates vendor-
specific queries) which is probably a good thing, but we
haven't provided any explicit support or testing for that yet.
Fixes gh-418
This commit adds auto-configuration and a starter,
spring-boot-starter-freemarker, for using FreeMarker view templates in
a web application.
A new abstraction, TemplateAvailabilityProvider, has been introduced.
This decouples ErrorMvcAutoConfiguration from the various view
technologies that Spring Boot now supports, allowing it to determine
when a custom error template is provided without knowing the details of
each view technology.
Closes#679
Salvatore has indicated that Jedis is his Java Redis client of choice.
This commit updates the auto-configuration support, actuator and
Redis starter accordingly.
Completes #745
The dependencies pom.xml now declares an import to the spring-data-releasetrain BOM pom.xml which in turn constraints version numbers for a dedicated release train release. This has the effect of users being able to upgrade to a certain release train by redeclaring the spring-data-releasetrain.version property to e.g. Dijkstra-M1. Individual modules can be upgraded by simply declaring the dependency in the desired version manually in a <dependencies /> or <dependencyManagement /> block.
Removed the explicit declaration for Spring HATEOAS as it is pulled in transitively by Spring Data REST anyway and thus makes sure it's in a compatible version.
Hibernate is picky about javassist, but unfortunately that
library is used by other parts of our stack (Thymeleaf!?), so
we need a policy for resolving the dependency transitively.
I fixed it to the version in Hibernate 4.3.1 (our current
best foot forward), but it will have to be updateed whenever
Hibernate is.
Fixes gh-402
Update AbstractRepositoryConfigurationSourceSupport to use the newly
introduced RepositoryConfigurationDelegate instead of effectively
reimplementing Spring Data Commons functionality which was prone to
changes in the API (code that wasn't considered to be API in the first
place).
Switch from implementing BeanClassLoaderAware to ResourceLoaderAware
to avoid having to set up a DefaultResourceLoader which should also
improve IDE integration.
Fixes gh-236
Disable Mongo auto-configuation when @EnableMongoRepositories is used
and adapt the test helper classes accordingly.
Change the property prefix and dependency management version property
from `...mongo` to `...mongodb` for consistency with Spring Data.
Fixes gh-315
Update `GroovyCompiler` and `AetherGrapeEngineFactory` to use the
recently added `spring-boot-dependency-tools` in favor of loading
dependency information from a generated properties file.
Add a gradle `ResolutionStrategy` that resolves missing version numbers
using the `spring-boot-dependencies` POM.
This commit also introduces a new `spring-boot-dependency-tools` module
that provides programmatic access to the `dependencyManagement` section
of the dependencies POM.
Fixed gh-262
Upgrade to Tomcat 7.0.50, working around the potential
NullPointerException by also adding dependencies to
tomcat-embedded-jasper (which is now also required for Hibernate
Validator 5.0, see commit 377953babd)
Fixes gh-245
Update Hibernate Validator dependency to 5.0.2 and also include
Tomcat Jasper dependency. Jasper is required as it provides the
default ExpressionFactory implementation class
(org.apache.el.ExpressionFactoryImpl) which is indirectly
instantiated by Hibernate Validator.
Fixes gh-173
Main user-facing interface is still Counter/GaugeService but the
back end behind that has more options. The Default*Services write
metrics to a MetricWriter and there are some variants of that, and
also variants of MetricReader (basic read-only actions).
MetricRepository is now a combination of MetricReader, MetricWriter
and some more methods that make it a bit more repository like.
There is also a MultiMetricReader and a MultiMetricRepository for
the common case where metrics are stored in related (often open
ended) groups. Examples would be complex metrics like histograms
and "rich" metrics with averages and statistics attached (which
are both closed) and "field counters" which count the occurrences
of values of a particular named field or slot in an incoming message
(e.g. counting Twitter hastags, open ended).
In memory and redis implementations are provided for the repositories.
Generally speaking the in memory repository should be used as a
local buffer and then scheduled "exports" can be executed to copy
metric values accross to a remote repository for aggregation.
There is an Exporter interface to support this and a few implementations
dealing with different strategies for storing the results (singly or
grouped).
Codahale metrics are also supported through the MetricWriter interface.
Currently implemented through a naming convention (since Codahale has
a fixed object model this makes sense): metrics beginning with "histogram"
are Histograms, "timer" for Timers, "meter" for Meters etc.
Support for message driven metric consumption and production are provided
through a MetricWriterMessageHandler and a MessageChannelMetricWriter.
No support yet for pagination in the repositories, or for HATEOAS style
HTTP endpoints.
Nathan Voxland
Dave Syer
Andy Wilkinson
Brett Wooldridge
Phillip Webb
Spring Buildmaster
Daniel Fullarton
Sebastien Deleuze
Stephane Nicoll
Henryk Konsek
David Liu
Ramnivas Laddad
Josh Long
Mattias Severson
Max Bruchmann
Andy Wilkinson
Lukasz Kryger
Stephane Nicoll
Phillip Webb
Oliver Gierke
Maciej Walkowiak
Marten Deinum
Roy Clarkson
Artur Konczak
Dave Syer
Craig Walls
Christoph Strobl
Gary Russell
Christian Dupuis
Greg Turnquist
Artem Bilan
John Blum
TimmyStorms
Michael Nitschinger