It turns out that some downstream projects are going to
support both Spring Boot 2.2 and 2.3 versions (Spring Cloud).
This way they are going to compile against Spring Integration 5.2,
but possible have a runtime against Spring Integration 5.3.
* Restore `IntegrationFlowDefinition` from the previous version
to keep binary compatibility at runtime
* Messaging Annotations: process ReactiveMH
* Add support for `ReactiveMessageHandler` as a `@ServiceActivator` bean
* Wrap `ReactiveMessageHandler` in the `ReactiveMessageHandlerAdapter`
in the `ServiceActivatorAnnotationPostProcessor`
* Unwrap `ReactiveMessageHandlerAdapter` in the `AbstractMethodAnnotationPostProcessor`
for `ReactiveStreamsConsumer`
* * Add documentation for the `ReactiveMessageHandler`
& Reactive MongoDb channel adapters
* Infrastructure for ReactiveMessageHandler
We have now a `ReactiveMongoDbStoringMessageHandler` which implements
a `ReactiveMessageHandler`, but not a `MessageHandler` for possible
deferred subscriptions to the returned Reactor type
We don't have a proper application context processing for this
new type of message handlers
* Change a `ConsumerEndpointFactoryBean` to apply an `MH` and `RMH`
as possible types for handler
* Introduce a `ReactiveMessageHandlerAdapter` to wrap an `RMH`
into a `MH` for synchronous calls in the regular consumer endpoints
* Wrap an `RMH` into a `ReactiveMessageHandlerAdapter` for regular
endpoints and unwrap for `ReactiveStreamsConsumer`
* Add `RMH`-based ctor into `ReactiveStreamsConsumer` for target
reactive streams composition (`flatMap()` on the `RMH`)
* Remove a `DelegatingSubscriber` from the `ReactiveStreamsConsumer`
in favor of direct calls from the `doOnSubscribe()`, `doOnComplete()`
& `doOnNext()`
* Add an `onErrorContinue()` to handle per-message errors, but don't
cancel the whole source `Publisher`
* Use `Disposable` from the `subscribe()` to cancel in the `stop()`
- recommended way in Reactor
* Use `onErrorContinue()` in the `FluxMessageChannel` instead of
`try..catch` in the `doOnNext()` - for possible `onErrorStop()`
in the provided upstream `Publisher`
* Handle `RMH` in the `ServiceActivatorFactoryBean` as a direct handler
as well with wrapping into `ReactiveMessageHandlerAdapter` for return.
The `ConsumerEndpointFactoryBean` extracts an `RMH` from the adapter
for the `ReactiveStreamsConsumer` anyway
* Add XML parsing test for `ReactiveMongoDbStoringMessageHandler`
* Add `log4j-slf4j-impl` for all the test runtime since `slf4j-api`
comes as a transitive dependency from many places
* * Fix conflicts after rebasing to master
* * Fix typo in warn message
* Change `Assert.state()` to `Assert.isTrue()`
for `ConsumerEndpointFactoryBean.setHandler()`
* * Fix `ConsumerEndpointFactoryBean` when reactive and no advice-chain
* Fix race condition in the
`ReactiveMongoDbStoringMessageHandlerTests.testReactiveMongoMessageHandlerFromApplicationContext()`
* * Handle `ReactiveMessageHandler` in Java DSL.
Essentially request a wrapping into `ReactiveMessageHandlerAdapter`.
Describe such a requirements in the `ReactiveMessageHandlerAdapter` JavaDocs
* Some Java DSL test polishing
* Add Java DSL for `ReactiveMongoDbStoringMessageHandler`
* Propagate missed `ApplicationContext` population into an internally
created `ReactiveMongoTemplate` in the `ReactiveMongoDbStoringMessageHandler`
* Remove Boon dependency and its usage
* Remove overloaded methods from the `IntegrationFlowDefinition`
- we can simply rely now on the super class
* Remove (or rework) deprecated entities in the docs
* Fix tests for removed deprecated APIs
* Rework affected tests to JUnit 5
* Bring Spring Data MongoDb back to `2.3`;
essentially rely on Spring Data BOM for dependencies
* Change `mongodb-driver-reactivestreams` driver version back to `1.12.0`
* Upgrade to Spring Security 5.3 M1
* Fix MongoDb module to use `MongoDbFactory` class instead of new (not committed yet)
`MongoDatabaseFactory`
* Remove `uuidRepresentation()` configuration from the `MongoClients` factory usage -
that is going to be MongoDb driver 4 feature
* Optimize logic in the `ExpressionEvaluatingParameterSourceFactory`
do not compute object if they are present in maps.
Plus extract some common code to the method
* Use Gradle variants for publishing `optional` and `provided`
* Use some transitive dependencies explicitly from other modules
since all the optional dependencies are not pulled by Gradle any more
Fixes https://github.com/spring-projects/spring-integration/issues/3132
It turns out that Checkstyle EmptyBlock doesn't complain about
empty default ctor.
Plus a new check for `super();` call treats it as a violation
* Remove `super();` from all the no-arg ctors
* Code style clean up in the affected classes according
IDEA suggestions
* Fix new Sonar smells
* Alongside with existing `springAmqpVersion` & `springVersion`
also expose `springDataVersion` & `springSecurityVersion`
project properties.
These can be used in external CI plans for compatibility builds
* Fix `IntegrationGraphServerTests` for the current state of graph -
The node name is now based on the endpoint id, not a `MH` bean name
* Fix MongoDB tests for compatibility with the latest driver
* Shorten internal component names for graph
The long `IntegrationContextUtils.ERROR_LOGGER_BEAN_NAME` name
is used for `errorChannel` `LoggingHandler`'s endpoint.
It is too long for endpoint node in the graph meanwhile the
`errorChannel` is good everywhere
* Change an `IntegrationGraphServer` logic to shorten internal
component names before drawing a graph
* Introduce `IntegrationUtils.obtainComponentName()` for
shortening an internal name if any
* Use `IntegrationConfigUtils.BASE_PACKAGE` in the `IntegrationMBeanExporter`
instead of its own static property
* Remove `IntegrationConfigUtils.FACTORY_BEAN_OBJECT_TYPE` in favor
of introduced in SF `FactoryBean.OBJECT_TYPE_ATTRIBUTE`
* Rework affected test classes to JUnit 5
* Remove usage of deprecated options in the `@EnableIntegrationManagement`
* Document names shortening feature for graph
* * Improve `obtainComponentName()` function
* GH-3118: MessagingGW: Don't proxy default methods
Fixes https://github.com/spring-projects/spring-integration/issues/3118
The `GatewayProxyFactoryBean` proxies all the methods in the provided interface,
including `default` and `static`.
This is not what is expected from end-users.
* Proxy only `abstract` methods from the provided interface
* Introduce a `DefaultMethodInvokingMethodInterceptor` to call `default`
method on the interface using a `MethodHandle` approach for those methods
calling
* * Introduce a `proxyDefaultMethods` option to let to
restore a previous behavior
* Handle a new property from XML, annotations & DSL configurations
* Ensure that the property works in various tests
* Document the feature
* * Fix typo in the `build.gradle`
Fixes https://github.com/spring-projects/spring-integration/issues/3120
The messaging gateway method without arguments works as a
polling channel adapter.
In this case a Messaging Gateway component is present in the end of flow.
Therefore we treat it as an `outbound_channel_adapter`
The `GatewayProxyFactoryBean` really produces an Inbound Gateway
for downstream flow and its proxy becomes a start of the flow
* Determine a return type of the gateway method to indicate
that `void` one leads to the `IntegrationPatternType.inbound_channel_adapter`
instead of regular `IntegrationPatternType.inbound_gateway`
JIRA: https://jira.spring.io/browse/INT-4568
* Refactor `AbstractMessageHandler` and implement `MongodbReactiveMessageHandler`
* Rename `AbstractBaseMessageHandler` to `MessageHandlerSupport`
* Clean up code style and resolve possible Sonar smells
The `ClaimCheckOutTransformer` contains an `IntegrationPatternType.claim_check_in`
value for its `getIntegrationPatternType()`.
* Use correct `IntegrationPatternType.claim_check_out` instead
* Add `IntegrationPattern` contract to implement on the target components
which represent particular EIP
* Add `IntegrationPatternType` with an internal `IntegrationPatternCategory`
to return from the component implementing `IntegrationPattern`
* Parse `IntegrationPatternType` in the `IntegrationNode` for potential
use on the UI for drawing a particular icon
* More pattern representations
* Clean up Checkstyle
* Fix JavaDocs
* Add `integrationPatternCategory` assertion into the `IntegrationGraphServerTests`
* Add more IntegrationPattern implementations
* Provide some delegation and overriding logic whenever we have
components wrapping
* Fix unused imports
* Add `inbound_gateway` pattern indicator
* Add conditional on `expectReply` to indicate a component as an
`IntegrationPatternType.outbound_channel_adapter` or
`IntegrationPatternType.outbound_gateway`
* Make some code clean up in affected classes
* Add a `gateway` type for `@MessagingGateway`
* Comment the reason for `outbound_gateway` type in the `AbstractReplyProducingMessageHandler`
* Bump `IntegrationGraphServer.GRAPH_VERSION`
* Add new attributes into graph sample in the `graph.adoc`
* Document an `IntegrationPattern`
* Apply changes for version 5.3
* Rebased into `5.3-WIP`
* Add a `whats-new.adoc` note about an `IntegrationPattern`
* Move `What's New` into `changes-5.1-5.2.adoc`
* Remove version from the `XSD` files:
1. Align with SF
2. The version for XSD doesn't matter for the current jar version,
since only the version is available in classpath is from the current
jar version
3. Modify `spring.schemas` to map all the possible versions for XSD
into the current one in a jar.
This way target applications can upgrade without changing the version
for XSD location and we don't need to require `versionless` variant
any more
4. The jar in classpath can handle only its own XSD, so independently
of version or no-version variants we still may fail because the current
jar may not support end-user code any more - need some fix over there
anyway.
* Remove `checkTestConfigs` Gradle task since we don't worry about XSD
version any more
* Modify `schemaZip` Gradle task to populate XSDs into a distribution
still with a version to avoid overriding on-line XSDs for version `1.0.x`.
We may consider not do that since SF doesn't and just bite a bullet
for always overriding those on-line XSDs to the actual one from the latest
release.
Fixes https://github.com/spring-projects/spring-integration/issues/3129
The `CHAR` type in Oracle is for fixed length values.
If the value is not of expected length it is padded with whitespaces.
This causes wrong assumptions when we perform queries against tables.
* Change the `CHAR` into a `VARCHAR2` in those tables for Oracle
where we don't have values with a fixed length.
In fact only `MESSAGE_ID` comes with always fixed length as `36`
because it is fully based on the `UUID`
To ensure advice-chain applicability the provided plain
`MessageHandler` is wrapped into a `ReplyProducingMessageHandlerWrapper`
with its particular `.wrapper` bean name.
When we build a graph for integration components, we use a
`componentName` from the `IntegrationObjectSupport` to represent a
node for endpoint in the graph.
In most cases the component name is an endpoint id around a `MessageHandler`
* Populate the missed component name in a `ReplyProducingMessageHandlerWrapper`
in the `AbstractMethodAnnotationPostProcessor` so nodes in the graph has
a proper name for their endpoint in the application context
Related to https://github.com/checkstyle/checkstyle/issues/7322
To be able to build the project against `mavenLocal()`, add a
`mavenLocal` project property which can be specified as command line arg
`-PmavenLocal`, so a `mavenLocal()` is added into `repositories`
conditionally
It turns out that these properties have some reasonable defaults, but
Sonar plugin on Bamboo can't read them anyway.
So, we have to modify CI plan for respective values for the project
Remove `sonar.projectKey` & `sonar.projectName` properties from the
`sonarqube` task since they have a reasonable defaults according
plugin docs: https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-gradle/
It looks like the feature to override these properties in the Bamboo
plugin doesn't work properly
Related to https://github.com/checkstyle/checkstyle/issues/7306
According to discussion with Checkstyle team, we agreed to give us
project for testing their latest changes for regressions to avoid
situation like in the mentioned issue with `RequireThis`
* We expose a `checkstyleVersion` for Gradle command line to let to
provide a Checkstyle version externally.
This feature is going to be used on Checkstyle CI to run check in our
project against their SNAPSHOT
The command to run checks against external version is like this:
`./gradlew clean check --parallel -x test -PcheckstyleVersion=[CHECKSTYLE_VERSION]`
Where `[CHECKSTYLE_VERSION]` is a placeholder which should be replaced
with environment-specific variable or an explicit version.
