- republish certain events as `ApplicationEvent`s.
* * Add ApacheMinaFtplet to provide the same functionality with FTP
* Fix typo
* * Polishing javadocs and event toString() methods
Fixes https://github.com/spring-projects/spring-integration/issues/3003
Statically defined flows with a publish/subscribe channel invoke the
subscriptions in natural (declared) order.
The components in the flow are started by the application context in
phases (consumers, then producers) and bean declaration order within
each phase.
When a dynamically declared flow is started, the components are started
by the `StandardIntegrationFlow` in reverse order (last to first) so that
we don't start producing messages before the flow is fully wired.
This has the side-effect that pub/sub subscribers are invoked in an
unnatural (last to first) order.
All subscription sub-flows start with a bridge from the pub/sub channel
to the first component's input channel.
The `BroadcastingDispatcher` honors the `Ordered` interface.
Change the `PublishSubscribeSpec` to set the `order` property so that
subscribers are always invoked in the natural order, regardless of whether
the flow is statically or dynamically defined.
Fixes https://github.com/spring-projects/spring-integration/issues/2748
* Refactor more `MessageHandlingException`s to include `this` into an
exception message
* Revert using `MessagingException` in some places which really are not
about messaging.
This helps to wrap them into `MessageHandlingException` later in the
`MessageHandler` for the `BeanDefinition` reference
* Remove `volatile` from configuration properties in the affected
classes
* Remove already deprecated `JmsOutboundGateway.setPriority()`
* Add `resource` and `source` for `BeanDefinition` in the
`AbstractChannelAdapterParser` & `AbstractInboundGatewayParser`
* Document the feature
* `exclude group: 'org.springframework'` from all non-core Spring
dependencies to avoid CLASSPATH conflicts
* Remove suppress from from some modules which don't report compilation
warnings any more
* Fix deprecation warnings reported after upgrades
* 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
* After introduction an `rsocketFrameType` header in the message,
we don't need a custom `IntegrationRSocket` any more.
Fully rely on the `MessagingRSocket` from the Spring Messaging, only
handle properly a `RSocketFrameTypeMessageCondition.CONNECT_CONDITION`
for connections from clients to emit an `RSocketConnectedEvent`
* Copy a `ChannelSendOperator` from the Spring Messaging for the proper
reply handling, when we are interested in the source `Publisher`
subscription first.
See its JavaDocs for more info
* Reusing already `public PayloadUtils` instead of its method copies
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
For the `connect` frame Spring Messaging RSocket support has introduced
an new `@ConnectMapping` annotation.
* Use `@ConnectMapping` in the test controller's method to properly
map to the connection from the client
* Add support for the `MetadataExtractor` in the
`AbstractRSocketConnector`, `IntegrationRSocketMessageHandler`
and `IntegrationRSocket` for more flexible RSocket metadata
* Use `DefaultMetadataExtractor` in the
`IntegrationRSocketMessageHandler.afterPropertiesSet()` since the getter
is not available on the super class yet
* Use a `MetadataExtractor` in the `IntegrationRSocket` instead of an
old `CompositeMetadata` manipulation
* Use `PayloadUtils.retainDataAndReleasePayload()` since it is `public`
already
* Downgrade to the `rsocketVersion = '0.12.2-RC4'` since it looks like
the latest `1.0.0-RC1-SNAPSHOT` doesn't parse a frame properly on the
server side
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 `LongRunningTest` to rely on the `@EnabledIf` from Spring Test
Framework instead of deprecated now in JUnit 5
* Remove unnecessary stubbing in the `FileReadingMessageSourceTest`
