* GH-2988: Use `@Config(proxyBeanMethods=false)`
Fixes https://github.com/spring-projects/spring-integration/issues/2988
For faster startup (and possibility to compile to native code with GraalVM)
use a `proxyBeanMethods = false` on all the `@Configuration` classes
in the Framework
* Provide some other code style polishing
* * Fix Checkstyle violation
Fixes https://github.com/spring-projects/spring-integration/issues/2987
To resolve XSD files properly from the classpath, their HTTPS reference
must be present in the `spring.schemas` to avoid the Internet interaction
for resolving an XSD file
**Cherry-pick to 5.1.x, 5.0.x & 4.3.x**
* GH-2748: Add bean definition info into exceptions
Fixes https://github.com/spring-projects/spring-integration/issues/2748
In many cases Spring Integration stack traces doesn't contain any
relations to end-user code.
Just because a target project code mostly contains only a configuration
for out-of-the-box components without any custom code.
When exception is thrown from such an out-of-the-box component, it is
hard from the stack trace to determine a configuration source for those
components.
* Add a logic into the `IntegrationObjectSupport` to obtain a its own
`BeanDefinition` from the `BeanFactory` to include a `resource` and
`source` (if any) into the `toString()` representation, as well as add
a new `getBeanDescription()` to get such an info at runtime
* The `toString()` is simply used by `this` reference in the message
for `MessagingException` thrown from the `IntegrationObjectSupport`
implementations
* Modify an exception message for the `MessageTransformingHandler` and
`MessageFilter` to make it based on `this`.
The `AbstractMessageHandler` already includes `this` into its exception
message
* Modify a `AbstractConsumerEndpointParser` and
`AbstractAmqpInboundAdapterParser` (as a sample) to include a `resource`
and `source` into a `MessageHandler` `BeanDefinition`.
* Include an `IntegrationFlow` `BeanDefinition` `resource`
(`@Configuration` class) and its bean method as a `source` into all
child beans declared during flow parsing in the `IntegrationFlowBeanPostProcessor`
* Add `IntegrationFlowRegistrationBuilder.setSource()` for manually
registered flows: there is no configuration parsing phase to extract
such an info from `BeanFactory`
* Propagate that `source` into all the child beans provided by the
`IntegrationFlow`
* Modify a `LambdaMessageProcessor` exception message to include a
method info in case of `InvocationTargetException`
* Do not cast explicitly for `ConfigurableListableBeanFactory` in the
`IntegrationObjectSupport` to avoid tests modifications for mocking
directly into `ConfigurableListableBeanFactory`.
Use `instanceof` instead in the `getBeanDescription()`
* * Fix Checkstyle issues
* * Fix `IntegrationGraphServer` and `IntegrationMBeanExporter`
to rely on the `NamedComponent` for channel names instead of
always call `toString()` which is now much more than just a bean name
* Don't describe a `componentName` if it is the same as a `beanName`
* Check for parent `BeanDefinition` in the `IntegrationFlowBeanPostProcessor`
before calling its meta-info
* Fix tests according new `IntegrationObjectSupport.toString()` behavior
Unsophisticated Avro transformers for `SpecificRecord` implementations.
* * Fix DSL Factory
- transformer was changed to `<? extends GenericContainer>`; change the DSL to match
* * Restore test log4j
* * Revert to supporting only SpecificRecord
* * Fix assert
* * Add multi-type deserialization with fluent API
* Polishing for PR comments
* * Remove type mappings; Exxpression now returns the type (or class name)
* Cache types created from class names
* Add type header in "toAvro" transformer
* * Remove the type cache (already handled by the class loader)
* * Don't convert the class to String in the "toAvro" transformer
JIRA: https://jira.spring.io/browse/INT-2480
* Introduce `headers-function` option into the `aggregator` for merging
and computing headers for the output message based on the completed
group
* Implement a `DefaultAggregateHeadersFunction` and use it in the
`AbstractAggregatingMessageGroupProcessor` for default behavior with
possible injection for any other implementation
* Add `DelegatingMessageGroupProcessor` to wrap any other
`MessageGroupProcessor` implementations with possible usage of the
`headersFunction` if result is not a `Message` or `MessageBuilder`
* Make `AbstractCorrelatingMessageHandler.getOutputProcessor()` as
`public` rto give access to this option from the `AggregatorSpec` to
be able to inject a `headersFunction` in Java DSL configuration
* Add `AbstractIntegrationMessageBuilder.getHeader()` to get access to
some underlying header avoiding extra `Map` in case of `getHeaders()`
* Change a logic in the `AbstractMessageProducingHandler.produceOutput()`
to consult a `reply` for the `replyChannel` as well `routingSlip` header
if the `reply` is a `Message` or `MessageBuilder`
* Introduce a `AbstractMessageProducingHandler.messageBuilderForReply()`
and use it in `AbstractMessageSplitter` to avoid duplication
* Validate a new functionality in tests
* Fix `FileOutboundGatewayParserTests` to rely on the `TemporaryFolder`
to clean up test files after using
* JavaDocs for `DefaultAggregateHeadersFunction`
* Some `router.adoc` polishing
* Fix link to Reactor in the `router.adoc`
* Add docs for new `Function<MessageGroup, Map<String, Object>>` strategy
* Doc polishing.
* Fix `SmartLifecycle.stop(Runnable)` usage
We always have to call `callback` in the `SmartLifecycle.stop(Runnable)`
implementation independently of component state
* Fix `StandardIntegrationFlow.stop(Runnable)` for a logic when we
don't have any `this.lifecycles`
* Remove those `stop(Runnable)` which are fully equivalent of the
`default` on in the `SmartLifecycle`
* Some other simple polishing for the affected classes, e.g.
`isSingleton()` is `default` with `true` in the `InitializingBean`
**Cherry-pick to 5.1.x**
* * Fix checkstyle violation
* GH-2967: Fix ScatterGatherH for headers copy
Fixes https://github.com/spring-projects/spring-integration/issues/2967
The `ChannelInterceptor` is added into the `this.gatherChannel` on each
request message making a subsequent requests for scatter-gather as
halting on reply.
* Add an interceptor into an injected `this.gatherChannel` only once
during `ScatterGatherHandler` initialization
* Introduce `ORIGINAL_REPLY_CHANNEL` and `ORIGINAL_ERROR_CHANNEL`
headers to carry a request reply and error channels from headers
* Populate `REPLY_CHANNEL` and `ERROR_CHANNEL` headers back before
sending scattering replies into gatherer
* Transfer a `GATHER_RESULT_CHANNEL` header now directly from the scatter
message to make it available in the reply from the gatherer
* Add note about those headers in the `scatter-gather.adoc`
* Modify `ScatterGatherTests` to be sure that `ScatterGatherHandler`
works for several requests
**Cherry-pick to 5.1.x**
* * Fix language in doc
JIRA: https://jira.spring.io/browse/INT-3073
Add `FluxAggregatorMessageHandlerTests`
* Add `FluxAggregatorMessageHandlerTests`
* Fix `FluxAggregatorMessageHandler` for the default `messageForWindowFlux`
to rely on the `publish().autoConnect()` to build a target `Flux` for
window and also copy headers from the first `Message` in the window.
Looks like `switchOnFirst()` doesn't work somehow with windows or I just
don't use it properly, although it isn't clear how to continue chain but
get the whole `Flux` as a single entry for message payload
* Add more tests for `FluxAggregatorMessageHandlerTests`
* Fix `AbstractMessageSplitter` to cast properly a primitive array
* Implement `Lifecycle` in the `FluxAggregatorMessageHandler`
* Add JavaDocs into the `FluxAggregatorMessageHandler`
Javadoc polishing
* GH-2880: Handle `Pausable` in Control Bus
Fixes https://github.com/spring-projects/spring-integration/issues/2880
* Refactor `ControlBusMethodFilter` to handle `Pausable` managed operations
* Optimize and internal `ControlBusMethodFilter.filter()` logic to rely
on the `MergedAnnotations`
* Modify `EnableIntegrationTests` to test new functionality and document
the feature
* * `ControlBusMethodFilter` to deal with plain `Lifecycle` impls as well
Since SF has deprecated `StandardAnnotationMetadata` ctors in favor
of factory method, we can't extend it any more to adapt annotation
attributed by the map generated from the XML attributes
* Introduce an `AnnotationMetadataAdapter` to request a
`getAnnotationAttributes()` implementation which is only a method used
in the target `registerBeanDefinitions()` implementations
* Use a new `AnnotationMetadataAdapter` whenever the `StandardAnnotationMetadata`
has been used before
* Move SF dependencies to the latest BUILD-SNAPSHOT
To avoid class loader issues it is better to align Spring Data
dependencies with SF version we use explicitly.
This way we don't have a `ClassLoader` issue when a newly introduced
`TransactionManager` might not be visible from the previous versions
* Fix code style warnings in the `TransactionSynchronizationFactoryBean`
* Use `JavaUtils` in the `TransactionSynchronizationFactoryBean` to
decrease code complexity
* * Fix CQ Gemfire tests for upgrades compatibility
* For better performance and consistency use a `MergedAnnotations` in
the `MethodAnnotationPublisherMetadataSource` instead of
`AnnotatedElementUtils`
* Remove deprecated API from the `PublisherMetadataSource` hierarchy
* use equals
* inner assignment
* local before return
* unnecessary locals
* catch and throw
* uninstantiable with no statics
* implement `Serializable` in `Comparator` to enable `TreeMap` serialization
* exceptions as flow control
Fixes https://github.com/spring-projects/spring-integration/issues/2908
* make sure the attribute is taken into account in @Header annotation
* remove useless spaces according to checkstyle rules
* make sure the expression attribute is taken into account as well in @Payload annotation
* Add initial support for RSockets
* Add `spring-integration-rsocket` module and respective dependencies
* Implement `RSocketOutboundGateway` based on the Spring Messaging
`RSocketRequester`.
This component supports dynamic RSocket properties via expressions
against request message.
to handle `Publisher` for requests, it must be present in the request
message `payload` instead of `FluxMessageChannel` upstream, since the
last one just flattens events to be handled in the `MessageHandler` one
by one.
The result `Mono` is subscribed downstream in the `FluxMessageChannel`
or directly by the `AbstractReplyProducingMessageHandler`.
If result is a `Flux` it is just wrapped into the `Mono` to be processed
downstream by end-user code.
The point is that these request/replies are volatile and live in the
particular context meanwhile a `FluxMessageChannel` is long living
publisher in the application context boundaries.
* The `RSocketOutboundGatewayIntegrationTests` is an adapted copy of
`RSocketClientToServerIntegrationTests` from Spring Messaging
* Add `doOnError()` into the `Flux` created in the
`AbstractMessageProducingHandler` for `Publisher` replies
* * Use singular for the `RSocket` term
* Use no-op `Consumer` for the `strategiesConfigurer` and
`factoryConfigurer` in the `RSocketOutboundGateway` and also
`Assert.notNull()` in the appropriate setters to avoid null check during
`RSocketRequester.builder()` initialization
* Use `TcpServer.create().port(0)` in the
`RSocketOutboundGatewayIntegrationTests` to allow to select free OS port
and bind into it.
The selected port is used later for client configuration in the
`RSocketOutboundGateway` bean definition
* * Change `RSocketOutboundGatewayIntegrationTests.PORT` to lower case
* Fix `AbstractMessageProcessingTransformer` to react for the
`AbstractIntegrationMessageBuilder` invocation result and don't wrap it
into the `Message`
* Demonstrate functionality in the `CacheRequestHandlerAdviceTests`
* Polishing and Docs
* Fix JavaDocs warnings
Doc polishing.
