https://build.spring.io/browse/INT-MJATS41-1242
When different `DefaultLockRepository` instances use the same client id,
there is a possibility that they will update the same row in the table.
This way we have a chance that not only one obtains a lock and try to
add a value to the collection.
* Remove the test-case for the same client id as non-stable and even
dangerous by the the distributed lock purpose
* Use `tryLock(Long.MAX_VALUE)` to really ensure the wait behavior
during the concurrent loop
* Use `20` for thread pool to align with the tasks amount
**Cherry-picked to 4.3.x**
https://build.spring.io/browse/INT-SI43X-230
Looks like Ruby engine takes some time to start and
`Jsr223InboundChannelAdapterTests` is slow as 3 seconds locally as well
* Change the script to JavaScript and now we have 200 millis
**Cherry-pick to 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4366
The `MulticastSendingMessageHandler.getSocket()` doesn't guard around
`this.multicastSocket` property causing `NPE` and other inconsistency
in the multi-threaded environment
* Make the whole `MulticastSendingMessageHandler.getSocket()` as
`synchronized` like it is with the super method
* Reuse `closeSocketIfNeeded()` in the
`UnicastSendingMessageHandler.handleMessageInternal()`
* Fix type in the `UnicastSendingMessageHandler` logging message
* Fix `UdpChannelAdapterTests` for missed `BeanFactory` for the SpEL
and also `MulticastSendingMessageHandler.stop()` in one missed places
**Cherry-pick to 4.3.x**
https://build.spring.io/browse/INT-MASTER-901
The `JdbcLockRegistryDifferentClientTests.testOnlyOneLock()` relies
on the `ArrayList.isEmpty()` state to proceed with the logic.
But since the `ArrayList.size` property is not `volatile`, there is no
guarantee for the proper state in the multi-threaded environment like
we have in this test-case.
* Replace `ArrayList` in the test with the `LinkedBlockingQueue` which
already rely on the `AtomicInteger` for the `size` property
* Fix `JdbcLockRegistry` tests to shutdown used `ExecutorService` s
to ensure set free threads after test suite execution.
**Cherry-pick to 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4382
There is a deadlock in the FMWH due to lock ordering.
Writes try to lock the handler monitor while holding the file lock.
The `Flusher` tries to lock the file lock while holding th handler monitor.
- Change the `Flusher`, `stop` and `flushIfNeeded` methods to not call close
on the file state while holding the handler monitor.
__cherry pick to 4.3.x__ (fix <> for Java 6)
Polishing - PR Comments
* Optimize `flushIfNeeded(FlushPredicate)` to delegate only to the
`flushIfNeeded(MessageFlushPredicate, Message<?>)`
* INT-4366: Fix MulticastSendingMessageHandler
JIRA: https://jira.spring.io/browse/INT-4366
Fix race condition in the `MulticastSendingMessageHandler` around
`multicastSocket` and super `socket` properties.
* Synchronize around `this` and check for the `multicastSocket == null`.
This let the `MulticastSendingMessageHandler` to fully configure and
prepare the socket for use.
* Remove `socket.setInterface(whichNic)` since it is populated by the
`InetSocketAddress` ctor before
**Cherry-pick to 4.3.x**
* Fix thread leaks in TCP/IP tests
JIRA: https://jira.spring.io/browse/INT-4379
- shutdown the container when the gateway is stopped
Also, improve test suite
- at the end of the tests, hundreds of threads are running, some caused by the above
but others because `TaskExecutor`s are not shut down
- reduce the number of iterations in the JMS pipeline tests to speed things up
- change more tests to extend `ActiveMQMultiContextTests`, to keep a single broker up
__cherry-pick to 4.3.x__ (perhaps just the gateway fix)
Fixes https://github.com/spring-projects/spring-integration/issues/2301
* For non-ordered, without deduplication logic use-case the `ArrayList`
option for internal `SimpleMessageGroup` collection is added
* Make `SimpleMessageGroup` `protected` ctor as `public` for better
reuse in case of custom `MessageGroupFactory`
To avoid `Message` re-creation during `AbstractMessageSource.receive()`
logic, refactor `AbstractMessageSource` implementations
to return `AbstractIntegrationMessageBuilder`
* Add `AbstractIntegrationMessageBuilder<File> doReceive()` to the
`FileReadingMessageSource` to be called from the `AbstractInboundFileSynchronizingMessageSource`
to avoid message recreation in its `doReceive()`
* Some code style refactoring in the `AbstractMessageSource`
JIRA: https://jira.spring.io/browse/INT-3945
Adding test for async annotated ServiceActivator
fix whitespace
Address comments
Change copyright and author
* Some code style polishing
* Rename `Log4j2LevelAdjuster.level()` to more friendly `forLevel()`
factory method name.
* Add `@param level` to the `Log4j2LevelAdjuster.forLevel()` to fix
JavaDoc warning
* Add `WrappedJsonNode.getTarget()` API to let target users to get
access to the target `JsonNode` for their logic
* Some code style and JavaDocs improvements in the `JsonPropertyAccessor`
The `SpelPropertyAccessorRegistrar` ctor and
`add(PropertyAccessor... propertyAccessors)` method use wrong variable
to build a key for the provided `PropertyAccessor`.
Therefore during iteration the next `PropertyAccessor` overrides the
previous and we end up just only with one instance in the registry
* Extract `private static obtainAccessorKey()` method to build
decapitalized key for the `PropertyAccessor`
* Change the map store to the `LinkedHashMap` to keep order of the
provided `PropertyAccessor` s
* Modify `EnableIntegrationTests` to ensure that we support several
`PropertyAccessor` s and in the proper order
**Cherry-pick to 4.3.x**
* INT-4376: Upgage to Log4J 2
JIRA: https://jira.spring.io/browse/INT-4376
* Deprecate Log4J 1.x components in favor of newly added
a `Log4j2LevelAdjuster` JUnit `@Rule`
* Update all the logging configuration to Log4J 2
* Polishing after testing
* add `BodyExtractor` support for Outbound part
* add `ClientHttpResponseBodyExtractor` as identity function
* add XML configuration for the Inbound part
* document `BodyExtractor` and Inbound XML support
Rename `replyToFlux` property to the `replyPayloadToFlux`
Doc Polishing
JIRA: https://jira.spring.io/browse/INT-4371
Add an abstract message source that populates the message with a header containing
an abstraction that allows the application to acknowledge/reject/requeue the message.
(In amqp, for example, this would map to channel.basicAck(tag),
channel.basicReject(tag, false), and channel.basicReject(tag, true).
With some brokers (such as kafka), acknowledge and reject might be equivalent
since there is no automatic DLQ processing in kafka both would simply commit the offset.
Also include a strategy interface for a factory to provide the acknowledgment header.
Add MessageSourcePollableChannel
Fix typo
Polishing - PR Comments
- remove marker interface; just use presence of the header for auto-ack
- remove the MessageSourcePollableChannel - users can use a MethodInterceptor to enhance the message
- other PR comments
Save entire response to allow customization of the ack/nack actions.
Docs, Copyrights; add MessageSourcePollingTemplate
Polishing - PR Comments - support disabling auto-ack, when possible.
More Utilities
* Simple code style polishing
When the target Java Bean reader throws an exception it is wrapped to
the `InvocationTargetException` which `getMessage()` returns `null`.
* Extract the `cause` when `InvocationTargetException` and check the
`message` for null anyway.
* Also check for `null` before calling `toString()` in the
`SimpleJsonSerializer.toElement()`
Fixes: spring-projects/spring-integration#2300
To allow to consume a streaming HTTP response downstream expose
`replyToFlux` option on the `WebFluxRequestExecutingMessageHandler`.
This way the body of the HTTP response can be converted now to the
`Flux` for subsequent output message.
The option is `false` by default; can be changed to `true` in the `5.1`
JIRA: https://jira.spring.io/browse/INT-4367
When CGLIB proxy is used for messaging POJO invocation,
the `InvocableHandlerMethod` doesn't recognize method parameter
annotations and therefore the logic is wrong at runtime or just
rejected during method processing
* Use `AopUtils.selectInvocableMethod()` to select the proper method to
call according the provided proxy type
Fixes: spring-projects/spring-integration#2243
The Message is indeed a result of `MessageChannel` consumption, but
definitely not a part of interaction with the tarter system.
For example `FileWritingMessageHandler` obviously writes to file,
but don't produce any messages
