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
Nathan Voxland
Phillip Webb
Andy Wilkinson
Stephane Nicoll
Dave Syer
Brett Wooldridge
Spring Buildmaster
Daniel Fullarton
Sebastien Deleuze
Henryk Konsek
David Liu
Ramnivas Laddad