Update Spring Integration metrics support since Spring Integration
`4.3.6`+ no longer needs `spring-integration-jmx` enable
`MessageChannel`, `MessageHandler` and `MessageSource` metrics.
- Add `IntegrationManagementConfiguration` conditional auto-configuration
to provide `@EnableIntegrationManagement` when JMX is `enabled` or there
is no `IntegrationManagementConfigurer.MANAGEMENT_CONFIGURER_NAME` bean.
By default this bean doesn't exist and you explicitly should declare it
(e.g. via `@EnableIntegrationManagement`) if you would like to collect
metrics. At the same time Spring Integration enables it when JMX
management is present (that is a purpose of that new
`IntegrationManagementConfiguration`)
- Change `SpringIntegrationMetricReader` to read metrics from the
`IntegrationManagementConfigurer`, not `IntegrationMBeanExporter`
- Change `PublicMetricsAutoConfiguration` to register
`IntegrationManagementConfigurer.MANAGEMENT_CONFIGURER_NAME` bean if
not present. Since we are here in `actuator`, therefore we are
interested in the metrics for SI as well.
- Since we don't need JMX for the metrics any more, remove SI-JMX
dependency from the `spring-boot-starter-integration`.
- Remove `IntegrationManagementConfiguration` modification from the
`integrationMbeanExporter()`, since that looks like mutation of an
external object, when end-user would prefer their own options.
Therefore we don't need `ObjectProvider<IntegrationManagementConfigurer>`, too
- Add missed `MessageSourceMetrics` gathering for the
`SpringIntegrationMetricReader`
Closes gh-7722
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