Resolves https://github.com/spring-projects/spring-integration/issues/3470
In order to catch issues like this at compile time, we need to set
the `bootClasspath` to ensure API compatibility but this would need some
consistent way to point the JDK 8 libs on all platforms (CI, GitHub Workflows,
dev machines, etc).
* More GH Actions goodies
* Add RabbitMQ, MongoDB & Redis services into GH actions
* Remove Travis
* * Add `distributionSha256Sum` into `gradle-wrapper.properties`
* Try `TERM: dumb` to see difference for Gradle output in GH action
* Add `-S` to see the reason of test failure
* * Try MQTT plugin for RabbitMQ image
* * Try `-i` for test failure in Gradle on Actions
* * Use `eclipse-mosquitto` image for MQTT on actions
* Fix `FtpServerOutboundTests` for the proper FTP file list
* Output file list for the failed session in the `RotatingServersTests`
* * Adjust SOUT in the test for Checkstyle
* * Make some change to `RotatingServersTests`.
Looks like the order for `@BeforeAll` methods is not determined
and we may start to interaction with FTP server which is not
started yet
* Fix SSL Handshake Test
- we already made this change for the NIO test, but the NET test is failing the same
way - the cert failure switched to the server so the expected exception was not
thrown on the client side. Due to JVM changes.
* * Fix SFTP tests for wrong host and auto-startup state
* Remove `-i` for Gradle in the GH Actions
* * Try `--no-parallel` for Gradle in the GH Actions
* * Try GH actions without Mosquitto
* * Try `cyrilix/rabbitmq-mqtt` for GH Actions
Co-authored-by: Gary Russell <grussell@pivotal.io>
* Rely on `MProducerSupport.active` for `Flux`
* Fix `MessageProducerSupport` to extract an `active` flag and set it before
`isRunning` - the `Flux` subscription relies on the `takeWhile()`
where in case of `autoStartup = false` we will never start consume because
it is set to `true` already after `doStart()`
* Refactor all the `MessageProducerSupport` implementation with similar
`active` state to use already one from the super class
**Cherry-pick to 5.3.x**
* * Remove `MessageProducerSupport.setActive()`
to not let to mutate it from the implementations
* Set `active` to `false` in the `destroy()`
* Clean up and fix typos in the affected `JmsMessageDrivenEndpoint`
* * Pull `active` flag down to the `AbstractEndpoint`
* Set `active = true` in the `start()` before calling `doStart()`
* Do same for `active = false` in the `stop()`
* Clean up `AbstractEndpoint` impls to not call `doStart/doStop` for nothing
* Refactor endpoints to rely on the `active` state from the `AbstractEndpoint`
not their own
* Remove redundant `@SuppressWarnings("deprecation")`
* Add `Duration.ofSeconds(10)` to `StepVerifier.verify()`
to avoid infinite wait and lose failing text context on the hang CI build
- Simplify MBeans - instead of wrapping to expose lifecycle methods,
implement `ManageableLifecycle`. Register an additional MBean for
polled endpoints to control the lifecycle.
* Polishing
- Move `QueueChannel` `@ManagedAttribute`s to `QueueChannelOperations`
- Make all `AbstractEndpoints` `IntegrationManagedResource`s and remove `ManagedEndpoint`
to allow exposure of any `@Managed*` methods (including those on `Pausable`)
- Revert to `Lifecycle` for classes that are not related to endpoints
- Remove legacy metrics from docs
Close the pool so that any sessions returned after the factory is
`destroy()`ed are closed.
* Call `removeAllIdleItems()` in `close()`.
* Close sessions in `SftpStreamingMessageSourceTests`.
**cherry-pick to all supported branches**
* Use new `joinGroup(SocketAddress, NetworkInterface)` API
* Resolve `NetworkInterface` in UDP components as
`getByInetAddress(InetAddress.getByName(localAddress))`
* join group as `socket.joinGroup(new InetSocketAddress(this.group, 0), null);`
* Fix `SocketTestUtils.chooseANic()` to select a real `NetworkInterface`
bound to a real IP address
* Fix `MulticastRule` to populate a `multicast.local.address` against a
host name for the network interface not an interface logical name
* Support Java 14
* Provide changes to avoid deprecated Java API
and have a compatibility back to Java 8
* Change affected test classes to JUnit 5 whenever it is possible
* Ignore/Disable some TCP/IP tests which don't pass on Java 14
* Fix (some) TCP tests on JRE 14
* Fix SSL Handshake test - client side handshake is successful with java 14
- change the badClient cert to a badServer cert to force an error on the client side
Co-authored-by: artembilan <raven666>
Co-authored-by: Gary Russell <grussell@pivotal.io>
Resolves https://github.com/spring-projects/spring-integration/issues/3299
Connect before creating the `TcpNioConnection` object and publishing the
`TcpConnectionOpenEvent`.
This was a regression caused by supporting connect timout; which moved
the connect to after the object was created and event published, causing
the `connectionId` to start with `unknown`.
**cherry-pick to 5.3.x, 5.2.x**
Resolves: https://github.com/spring-projects/spring-integration/issues/3199
Previously, the FCCF did not cache a shared connection; if server 1 is down
and server 2 is up, this caused an attempt to connect to server 1 every time
we got the connection.
Add 2 options: `refreshSharedInterval` and `closeOnRefresh`, defaulting to
0 and false respectively, to maintain the same behavior as before the options
existed.
Disallow caching of the single shared connection if the delegate factories are
`CachingClientConnectionFactory` instances.
**cherry-pick to 5.2.x**
I will backport to 5.1.x, 4.3.x after review/merge.
* Polish javadocs and fix typo in docs
* GH-3155: Add support for Java DSL extensions
Fixes https://github.com/spring-projects/spring-integration/issues/3155
Provide an `IntegrationFlowExtension` for possible custom EI-operators
in the target project use-cases.
* * Move `IntegrationFlowExtension` tests ot its own test class
* Make all the `IntegrationComponentSpec` ctors as `protected` for possible custom extensions
* Make some `BaseIntegrationFlowDefinition` methods and properties as `protected` to get them
access from the `IntegrationFlowExtension` implementations
* Document the feature
* * Fix language and typos in docs
* * Add `protected` to one more `GatewayEndpointSpec` ctor
* Add JavaDocs to `GatewayEndpointSpec` methods
* * Add `protected` to one more `JmsPollableMessageChannelSpec` ctor
* 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
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
* 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/3107
The `MessagingGatewaySupport` has an `errorOnTimeout` option to throw
a `MessageTimeoutException` when downstream reply doesn't come back in
time for configured reply timeout
* Expose an `errorOnTimeout` option as a `TcpInboundGateway` ctor
property
* Add new factory methods into a `Tcp` factory for Java DSL
* Ensure a property works as expected in the `IpIntegrationTests`
* Document a new option
* Add a setter for MessagingGatewaySupport.errorOnTimeout option
* Expose an `errorOnTimeout` option on the DSL's `MessagingGatewaySpec`
making all the out-of-the-box inbound gateways possible to react to the
`MessageTimeoutException` when no reply during reply timeout
* Propagate properly `errorOnTimeout` in the `JmsInboundGateway`
* Modify docs respectively
* Improve docs about `errorOnTimeout`
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
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