Turns out PUB socket doesn't care if there are subscribers to it or not.
The sent message may be just lost in between.
* Resend message in the test until it is received by subscriber
* Use `await().untilAsserted()` to iterate the logic at most 10 seconds
* Fix dynamic Websocket endpoints for SockJS
Related to https://stackoverflow.com/questions/67971467/registration-of-dynamic-websocket-at-application-initialization-time-and-at-runt
The SockJS wrapper for dynamic endpoint is not initialized properly.
Technically we just don't map to the SockJS service if such one is requested from the `ServerWebSocketContainer` configuration
* Postpone the path mapping for the target endpoint until after the `ServerWebSocketContainer` applies all the options
into its registration to expose.
* Fix `ServerWebSocketContainer` to propagate a default `TaskScheduler` for underlying SockJS Service on the endpoint
* Fix `IntegrationDynamicWebSocketHandlerMapping` to deal with path patterns as well, which is the case for the mentioned SockJS wrapper:
the SockJS Service is able to handle the rest of the path according its setting and request requirements
* * Fix unused imports
* Add Javadoc for new `ServerWebSocketContainer.setSockJsTaskScheduler()` API
* * Cover SockJS server configuration in the WebSocketDslTests
Related to https://stackoverflow.com/questions/67923303/dynamic-registration-of-websocket-output-adapter-is-not-working
By default the `AbstractHandlerMapping` comes with the `order = Ordered.LOWEST_PRECEDENCE` which sorts
added mappings to the end of chain.
At the same time Spring Boot registers a `SimpleUrlHandlerMapping` as a fallback for all not handled requests
leaving our own mapping behind consideration
* Add `order = 0` to the `IntegrationDynamicWebSocketHandlerMapping` bean registration to let it to be
consulted before `SimpleUrlHandlerMapping`
* Add a note into `web-sockets.adoc` that `@EnableWebsocket` would disable Spring Integration dynamic WebSocket
endpoints
Fixes https://github.com/spring-projects/spring-integration/issues/3578
The `JdbcTemplate.queryForMap()` extract values for columns to the closer target driver types.
For example H2 and Derby return `Long` for `BIGINT`.
Oracle for its `NUMBER(19,0)` returns `BigInteger`.
This makes the code in the `JdbcMessageStore.getMessageGroup()`
not platform independent.
* Fix `JdbcMessageStore` to map `ResultSet` to the `MessageGroupMetadata`
directly.
Mostly reinstating the previous behavior
* For that reason expose a default ctor for `MessageGroupMetadata`
and extract some setters to make code in the `JdbcMessageStore` more cleaner.
* This opens for us a possibility to implement a `MessageGroupStore.getGroupMetadata(groupId)`
for `JdbcMessageStore`
* Fix deprecation for `Flux.limitRequest()`
* Add a link from the HTML to the PDF and vice-versa.
* Update doc link text
* I missed that we have three formats: single-page HTML, multiple HTML pages, and PDF.
This commit links the single-page HTML and PDF to the other two formats.
Fixesspring-projects/spring-integration#3570
The module file with the Gradle metadata cannot be published on Maven
Central, which causes issues for some people using a repository manager such
as Artifactory. If it doesn't return a 404 HTTP status, the build fails
instead of ignoring the module.
**Cherry-pick to `5.4.x` & `5.3.x`**
Fixes https://github.com/spring-projects/spring-integration/issues/3567
* Retry for TransactionSystemException in JdbcLockRegistry
* Unit test added for `TransactionSystemException`
* Completing author and copyright year information
**Cherry-pick to `5.4.x` & `5.3.x`**
Fixes https://github.com/spring-projects/spring-integration/issues/3451
The GreenMail provides a comprehensive support for e-mail scenarios
testing.
* Use GreenMail instead our own `TestMailServer` for better and broader
support
* Convert SmtpTests and Pop3Tests to GreenMail
* Document that Pop3MailReceiver does not support autoCloseFolder=false
* Pop3MailReceiver uses `folder.getMessageCount()` to determine if there
are new messages.
This count only gets updated when opening the folder.
* Use GreenMail for remaining mail tests
* convert MailTests and ImapMailReceiverTests to GreenMail
* remove duplicate mail dependencies
* route com.sun.mail logging to log4j (via jul and slf4j)
JIRA: https://jira.spring.io/browse/INT-2436
The `JmsChannelFactoryBean` creates a `ListenerContainer` internally
without any `beanName` propagation.
When we rely on a default internal `Executor`, it is created with a
default thread name prefix for all the JMS channel instances.
It cause a confusion in logs
* Set `beanName` for the internal `ListenerContainer` to `this.beanName + ".container"`
making its connection with a channel it is associated with and unique thread name prefix
* Comment out `allWarningsAsErrors = true` in `build.gradle` for deprecated Kotlin
language version `1.3`.
Otherwise IDEA doesn't want to build project
* Rework `DefaultMessageAggregatorIntegrationTests` to Junit 5
* Add `@DirtiesContext` to release a `TaskScheduler` resources
when the `ApplicationContext` is closed
* INT-1828: Docs about filter & release strategy
JIRA: https://jira.spring.io/browse/INT-1828
Document a corner case when filter endpoint is involved in
the flow logic before an aggregator with sequence size release strategy
* Fix typos in the doc changes
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
* GH-3504: Explain more an async error handling
Fixes https://github.com/spring-projects/spring-integration/issues/3504
The reaper for an aggregator (as we as a group timeout) are based on the
`TaskScheduler`.
If non-default `TaskScheduler` is used in the configuration, recommend to
supply it with a `MessagePublishingErrorHandler`
* Rewording changes for proper language
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
Related to https://github.com/spring-projects/spring-framework/issues/26892
The WebSocket tests with `allowedOrigins` fail now because CORS processor
in Spring Framework removes a trailing slash from the request where possible one
in the config is left as is.
* Remove the trailing slash from the CORS config to match the current SF behavior
Fixes https://github.com/spring-projects/spring-integration/issues/3560
According RFC 5322 `FROM` and `REPLY-TO` received mail message can be
as an array of addresses.
* Fix `MailUtils` to present those arrays as comma-delimited strings for
Spring message headers
* Fix tests to deal already with several addresses for `FROM` mime header.
In the future we may change the logic to map those mime headers to arrays
as it states according the mentioned RFC
**Cherry-pick to `5.4.x` & `5.3.x`**
Fixes https://github.com/spring-projects/spring-integration/issues/3558
Kotlin lambdas mostly used to configure endpoints in DSL manner
are not really Java lambdas, but rather anonymous classes implementing
respective Java interfaces.
While in most cases such classes carry generic info for their method impls
properly in Java, it is somehow doesn't work well for `GenericHandler`
implemented by Kotlin lambdas
* Wrap provided `GenericHandler` in the `BaseIntegrationFlowDefinition.handle()`
into a Java lambda and call `handle()` recursively to carry an expected type to
the `LambdaMessageProcessor`
* Fix `LambdaMessageProcessor` to handle `ClassUtils.isKotlinUnit()` result of
an invocation as a `null` reply
**Cherry-pick to `5.4.x` & `5.3.x`**
* GH-3554: Eval remote dir on each synchToLocal
Fixes https://github.com/spring-projects/spring-integration/issues/3554
The `remoteDirectoryExpression` was introduced into an
`AbstractInboundFileSynchronizer` to let end-user to evaluate a remote directory
on each poll (essentially on each `synchronizeToLocalDirectory()` call).
The fix for the https://jira.spring.io/browse/INT-4491 introduced a regression
when such an expression was evaluated only once when we call a `setRemoteDirectory()`.
So, an original purpose of this option was lost and we don't get an actual
remote dir on each poll
* Remove `evaluateRemoteDirectory()` method and its usage since it doesn't
reflect expectation of the remote dir expression property
* Reinstate the `remoteDirectoryExpression` evaluation in the
`synchronizeToLocalDirectory()`
* Propagate the result of that expression into further methods for copying
files
* Remove setting of the `remoteDirectory` variable into a global `EvaluationContext`
of the `AbstractInboundFileSynchronizer` instance since it is not thread-safe
* Instead create an `EvaluationContext` locally for each `synchronizeToLocalDirectory()`
call and set the `remoteDirectory` variable into this scoped instances
* Generate a local file name from the `localFilenameGeneratorExpression`
against locally created `EvaluationContext` with the mentioned `remoteDirectory` variable
* Cover the expected functionality with a unit-test
**Cherry-pick to `5.4.x` & `5.3.x`**
* * Fix `testRemoteDirectoryRefreshedOnEachSynchronization` according PR review
SO: https://stackoverflow.com/questions/67214907/zeromq-with-spring-spring-integration-zeromq
The `Mono` is created in several places in ZeroMQ components from their constructors.
That leads to the reactive stream to be configured just after ctor, which will ignore
any changes to the options which are used from that `Mono` definition.
For example this code `.doOnNext(this.sendSocketConfigurer)` is done once during
reactive stream definition.
* Fix all the ZeroMQ components to defer usage of the options which could be changed
after ctor initialization
* Cover affected option changes in the tests
**Cherry-pick to `5.4.x`**
The `AbstractPersistentAcceptOnceFileListFilter`
extends now an `AbstractDirectoryAwareFileListFilter`
and makes all the implementors to implement its `isDirectory()` method.
This is a breaking change in the point release which makes implementations
outside of the core project not compilable
The regression after: https://github.com/spring-projects/spring-integration/issues/3488
Related fix in the Spring Cloud GCP: https://github.com/spring-cloud/spring-cloud-gcp/pull/2654
* Implement an `isDirectory()` in the `AbstractPersistentAcceptOnceFileListFilter`
to let other implementations do not worry during upgrade
**Cherry-pick to `5.4.x` & `5.3.x`**
* Make `@IntegrationConverter` Native compatible
* Add `BASE_PACKAGE` into an `IntegrationContextUtils`;
deprecate similar in the `IntegrationConfigUtils`.
This fixes a package tangle between `config` and `context`
* Move `ConverterRegistrar` and `CustomConversionServiceFactoryBean`
into a `config` package since they are package protected and
created their instances in the `IntegrationConverterInitializer`
functional way instead of reflection
* Use new `IntegrationContextUtils.BASE_PACKAGE` constant instead of
deprecated one
* Make `DefaultConfiguringBeanFactoryPostProcessor` `public` to
make it available for Spring Native `trigger` option in the `@NativeHint`
declaration
* Simplify logic around `JsonPath` to just a `ClassUtils.isPresent()`
* Move the `@IntegrationConverter` processing logic into the `ConverterRegistrar`
to avoid reflection via `BeanDefinition` ctor arg manipulation
* Move the reflection logic into a `ConverterParser` which, being a part of XML
configuration, is not going to be compatible with native any way
* Mark `JsonNodeWrapperToJsonNodeConverter` with an `@IntegrationConverter`
since it is not registered via reflection any more
* Expose `MicrometerMetricsCaptorRegistrar.METER_REGISTRY_PRESENT` and use
it in the `IntegrationGraphServer`
* Extract `UnmarshallingTransformer.MIME_MESSAGE_PRESENT` for less
reflection at runtime
* Use `null` for a `ClassLoader` arg in the `ClassUtils.isPresent()`
relying on the default one internally
* * Fix Checkstyle violations
Currently the `MessageHistoryRegistrar` can parse several sources for message history -
`@EnableMessageHistory` and/or `<message-history>`.
Since its logic relies on the reflection it is not compatible with Spring Native.
Plus it causes confusion when several sources are declared so when time comes to
change something in that configuration, we may miss some place to re-align with
our new requirements.
Better to reject extra configurations and enforce end-users to use only one
`@EnableMessageHistory` or `<message-history>`.
This is actually a preferences for many other `@Enable...` in Spring portfolio.
Plus we got a benefit with a Spring Native compatibility
* Fix `MessageHistoryRegistrar` to parse only one `@EnableMessageHistory`.
Register `MessageHistoryConfigurer` function way for Spring Native compatibility
* Clean up `PublisherRegistrar` for better readability
* Fix message history tests which exposed several configurations
* Add JavaDoc into `EnableMessageHistory`
* Refactor `MessageHistoryConfigurer` to let to override patterns configuration
at runtime
* Clean up `message-history.adoc`
* Optimize `InboundOneWayErrorTests` to not close ctx after each test.
Probably will affect ActiveMQ connection to avoid a race condition
when it is not started yet, but we produce a message
