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
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
