Rework commit 4a69755b to remove the need for the ApplicationInfo class.
The updated code now uses the auto-configuration class to compute a
default persistence unit root location
Closes gh-6635
Due to the layout format change in 1.4, Spring Framework is no longer
able to compute a default persistence unit root URL. If a Spring Boot 1.4
application has JPA but does not have any entity, the application started
from a fat jar now fails with a quite cryptic exception.
This commit introduces `ApplicationInfo` as a general replacement for
the `ApplicationArguments` and `Banner` singleton beans that
`SpringApplication` registers on startup. `ApplicationInfo` also defines
the detected "main" `Class` that can be used to compute a last resort
URL that makes sense.
If such bean is available, `EntityManagerFactoryBuilder` now sets the
default persistence unit root location, preventing Spring Framework to
attempt to resolve an unknown location. Note that in our case the
persistence unit root location is actually useless: given the way the
persistence unit is created, nothing actually uses it but Hibernate, as a
compliant JPA provider, has to make sure this setting is set to a valid
URL nevertheless.
Closes gh-6635
The upgrade to Hibernate 5.2.0.Final has provide to be too
problematic to live with. It requires Java 8, is incompatible with
a number of other projects in the Hibernate ecosystem, and it's
unclear for how long it will be maintained. We'd previously used
Hibernate 5.1.0.Final but its maintenance is also unclear with
Hibernate 5.1.1.Final being more than 3 months overdue.
This commit drops back to Hibernate 5.0.9.Final. This has a few
advantages:
- It's Java 7 compatible
- It's had some time to mature and should be reasonably free of
regressions for those moving from 4.3.x
- It's used in both Wildfly and JBoss EAP so there's a fair chance
that it will continue to be maintained.
Closes gh-6198
This commit changes the default version of Tomcat to 8.5.3 while
also retaining support for Tomcat 8.0 and 7.0. The main difference
in 8.5 is that the ServerSocketFactory abstraction that allowed the
TrustStore and KeyStore to be configured programatically no longer
exists. This logic has been replaced with the use of a custom URL
protocol (springbootssl) that provides access to the key store and
trust store of an SslStoreProvider. In addition to working with 8.5,
this approach has the advantage of also working with 8.0 and 7.0.
Closes gh-6164
This commit removes HSQLDB dependency from Batch Starter as most apps
that use Spring Batch will prefer to use a RDBMS of their choice to store
batch metadata.
Additionally, explicit spring-jdbc dependency has been replaced with JDBC
Starter dependency.
See gh-6081
As of Spring Framework 4.3, spring-aop now embeds the classes from the
aopalliance:aopalliance jar. This means that the transitive dependency
on aopalliance:aopalliance is redundant and it can be excluded.
Closes gh-6159
This commit upgrades to MongoDB 3. Dependency management has been added
for the new and preferred mongodb-driver artifact. The starter has
been updated to use this new artifact rather than monogo-java-driver.
Dependency management for mongo-java-driver has been retained to avoid
causing problems for people who have declared the dependency explicitly.
The auto-configuration for Embedded Mongo has also been updated to
use 3.2.2 by default.
Closes gh-3011
"Starter POM" is a confusing term as it implies the starter may be a
POM while it's actually a jar artifact like any other dependency. To
reduce the confusion (especially in the way such starter should be
declared in the build), the term Starter POM has been renamed to Starter.
Closes gh-5966
This commit deprecates the `ws` starter in favour of a new `web-services`
starter. A deprecation warning auto-configuration has also been added to
the ws starter.
Closes gh-5711
This commit streamlines the Integration Starter by removing the file
http, ip, and stream modules as they are not always used by a majority
of apps that use Spring Integration and can also pull in other, unwanted
dependencies.
Additionally, a dependency on spring-integration-java-dsl has been
added. This makes it easy for users to configure Spring Integration
using Java configuration (the recommended approach), rather than via
XML. The Integration sample has been updated to use the DSL. Further
improvements could be made once the sample is using Java 8.
Closes gh-5528
Rename spring-boot-starter-webservices back to spring-boot-starter-ws.
Unfortunately the starter exists in Spring Boot 1.3 so we can't rename
it without consequence.
See gh-5711
In the web starter we shouldn't depend explicitly on any EL
implementation, otherwise when people build wars and deploy
them in containers that have their own EL there is a conflict.
We can still depend on hibernate-validator to support
JSR-303 in web apps because the EL implementation comes with
the container.
Fixes gh-5454
Previously, the documentation included hand-written tables for the
application, production, and technical starters.
This commit replaces the hand-written tables with tables that are
generated automatically from all of the starter poms, thereby ensuring
that the documentation is automatically kept up-to-date as starters
are added and removed. An extra column provided a link to each
starter's pom on GitHub has also been added to the table. This makes
it easier for users to see exactly what each starter contains.
Closes gh-5267
Add AssertJ as a managed dependency and also include it in
spring-boot-starter-test. Also provide a simple adapter class to allow
Hamcrest matchers to be used as AssertJ Conditions.
Fixes gh-5048
Our Investigations show that JNDI lookup is quite costly on Jetty and it
was enabled by default while embedded tomcat does not. This commit
excludes `jetty-jndi` to align the behavior with Tomcat.
If you are relying on JNDI, the `jetty-jndi` should simply be added in
your project.
Closes gh-4710
So far we have wrongly advertized that the `spring-boot-starter-parent`
filters application configuration in such a way that standard Spring
placeholders are not processed.
In order to achieve such feature, the `useDefaultDelimiters` property
must be set to `false` as otherwise default delimiters are appended to
the list of custom delimiters.
This property is not enabled so that only keys surrounded by `@` are
filtered by the build.
Closes gh-3092
AspectJ’s weaver module contains a superset of the classes found in
AspectJ’s RT module. This commit updates the starters to exclude
aspectjrt so that only aspectjweaver is on the classpath.
Closes gh-3975
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.
Initial update to the documentation to mention how a 3rd party starter
should be named. The current doc sends a completely inconsistent message
to what we actually intend.
See gh-2537
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
The documentation claims that JSPs don't work with embedded Jetty
making the dependency on jetty-jsp pointless. Furthermore,
spring-boot-starter-tomcat doesn't include JSP support and Undertow
doesn't support JSPs at all so removing jetty-jsp makes the embedded
container starters more consistent. It also removes 3.2MB from a
Jetty-based fat jar (spring-boot-sample-jetty drops from 12MB to
8.8MB).
Closes gh-2680
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
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
Sadly, Gradle handle's exclusions differently to Maven even when it's
processing a Maven pom.
In this case groovy-all is pulled in via org.crashub:crash.shell where
we've excluded it. This is enough to prevent Maven from pulling in
groovy-all when you depend on the remote shell starter.
org.crashub:crash.shell is also pulled in as a transitive dependency
of a number of other dependencies and Gradle requires each of these
to also exclude groovy-all for it to actually be excluded.
This commit adds the additional exclusions that are required to make
Gradle's behaviour sane.
Fixes gh-2257
Update maven-jar-plugin configuration in spring-boot-starter-parent
with `addDefaultImplementationEntries` so that implementation versions
are included by default.
Fixes gh-2266
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
Including maps and lists. Beans with no metadata (in
/META-INF/*spring-configuration-metadata.json) are just serialized
as they come (so might have problems like cycles). Serialization
errors are caught and rendered as an "error" for that bean. Any
problems can be fixed by preparing metadata and specifying which
properties are to be rendered that way.
Fixes gh-1746, fixes gh-1921
