AMQP Lambdas
Event Lambdas
Feed/File Lambdas
Gemfile/Groovy Lambdas
* Ensure that JavaDocs are checked via ` check.dependsOn javadoc`
* Add `@return` tag to the `MessageBuilder.readOnlyHeaders()`
JIRA: https://jira.spring.io/browse/INT-3913
* Remove deprecated classes and methods/constructors, deprecated XML attributes
* Remove `TcpConnectionEventListeningMessageProducer` and rework tests logic to the `ApplicationEventListeningMessageProducer`
* Fix several typos
* Remove/rework deprecated entities mentioning
See https://build.spring.io/browse/INT-AT42SIO-199/
In some places we start `Cache` but doesn't close/destroy it in the end.
That sometimes causes conflicts with the already started GemFire from other tests or wrong state around `BeanFactoryLocator`
* Ensure `Cache` destroy in the end of each test
* In addition destroy `Region` as well to avoid unexpected race conditions, too
* Plus optimize some tests to start `Cache` and `Region` only once per test class, not for each test method
From here I can say that it even would be better to start `Cache`, and therefore whole GemFire, only once per entire Gemfire module test suite.
But that is fully different story.
Remove `forkEvery` from Gemfire module
Allow get a performance improvement for the build.
The `gradlew clean :spring-integration-gemfire:testAll` with existing state is like:
```
Total time: 3 mins 41.375 secs
```
With this fix and without `forkEvery`:
```
Total time: 1 mins 42.699 secs
```
So, 2 min saved time!
Plus fix timeouts in the `PayloadSerializingTransformerParserTests`
JIRA: https://jira.spring.io/browse/INT-3387,
https://jira.spring.io/browse/INT-3806
* Introduce
```
MessageGroupStore
void addMessagesToGroup(Object groupId, Message<?>... messages);
```
And implement it in all stores.
* Use new `addMessagesToGroup` where it is reasonable, e.g. `DelayHandler`
* Optimize test-case to use a new store method (where it is possible)
* Fix timing delays in the `JdbcMessageStoreTests`
* Introduce `PersistentMessageGroup`
* Add `AbstractMessageGroupStore#proxyMessageGroupForLazyLoad` to wrap the raw `MessageGroup` to the `PersistentMessageGroup` for lazy-load
* Rework `MessageGroupMetadata` do not be `immutable` and allow to store/restore in the `AbstractKeyValueMessageStore` only the `MessageGroupMetadata`
* Refactor `ResequencingMessageHandler` and `SequenceSizeReleaseStrategy` a bit for better performance when interact with the `MessageGroup`
* Add `AbstractMessageGroupStore#setLazyLoadMessageGroups` to switch off the `lazy-load` behavior and restore the previous full `MessageGroup` logic
* Add `What's New` note and `message-store.adoc` paragraph for the lazy-load functionality
`GroupType.PERSISTENT` and not lazy by default
PR Comments
Fix `JdbcMessageStoreTests` timing issues
Address PR comments
* Add performance test to the `ConfigurableMongoDbMessageGroupStoreTests`
* Add JavaDocs for the `MessageGroupFactory` methods
* Add `log4j.properties` into the `test` MongoDB module for better traceability
* Fix `JdbcMessageStore#getOneMessageFromGroup()` over the `doPollForMessage()` delegation.
The `jdbcTemplate.queryForObject()` requires exactly one and only one raw in `resultSet`
* Add performance test results into the `message-store.adoc`
checkstyle EmptyBlock
checkstyle fixRightCurly Script
checkstyle EmptyStatement
checkstyle RightCurly
checkstyle TailingWhite
checkstyle NeedBraces
Fix the line separator in the `fixRightCurly.gradle`
* `gradlew clean check -x test --parallel --continue` - to collect reports
* `gradlew fixThis --parallel` - to fix all possible vulnerabilities. With `-Dfile.encoding=UTF-8` on Windows
Since the `RequireThisCheck` doesn't see parents for anonymous classes (e.g. `Runnable` callback), its report doesn't contains the outer class name with `this.`,
therefore we still have to fix those cases manually.
Thanks to the wrong `replacer` just with `this.` we have uncompilable code enough easy to find problems.
Not so easy to fix for good readability though...
* Upgrade to Grade 2.12
* Upgrade to SonarQube native plugin
The fix contains at about 300 files. So, will be done on merge.
Fix `fixThis.gradle` according PR comments
Apply `fixThis` and also `fixModifiers` for test classes.
Fix some `this.` inner issues manually.
Make code polishing for long lines after `fixThis`
Fix conflicts and vulnerabilities after the rebase
JIRA: https://jira.spring.io/browse/INT-3917
* Add `@DirtiesContext` to tests with application contexts
* Add `cache.close()`
* Add NPE check around `cache` in the `@After` methods
* Change a parser test to use mocks, not real Gemfire objects
**Cherry-pick to 4.2.x**
JIRAs:
https://jira.spring.io/browse/INT-3830https://jira.spring.io/browse/INT-3523https://jira.spring.io/browse/INT-3846
* Fix the OOM condition, when we `release()` `UpperBound` independently of the previous `remove` result (https://jira.spring.io/browse/INT-3846)
* Fix "confuse" around `groupCapacity`, when we really didn't care about individual groups (https://jira.spring.io/browse/INT-3523)
* Add `upperBoundTimeout` to have a hook to wait some time for the empty slot in the store (https://jira.spring.io/browse/INT-3830)
* Fix some JavaDocs warnings
* Fix some typos
* Fix inconsistency in the `DelayHandler` around `removeMessageFromGroup` when `MS` is `SimpleMessageStore`
* Remove `UpperBound.release()` operation from `SimpleMessageStore.removeGroup()`.
The waiting process should worry about the new `UpperBound` instance.
Some other polishing
`tryAcquire` outside of the `lock`
Move `tryAcquire` within the `addMessageToGroup` outside of `lock`.
But do that only for groups which already exist.
For the new groups we have a fresh `UpperBound`, so no need to worry about dead lock and
we can obtain a permit immediately.
SimpleMessageGroup: BlockingQueue -> LinkedHashSet
`SimpleMessageStore`: use "unsynchonized" `SimpleMessageGroup`
Make some synchronization fixes according to the migration to the `LinkedHashSet`
Avoid extra `Collection`
`ResequencingMessageHandler`: compare `size()` of collections instead of `containsAll()`
Fix `ConcurrentModificationException` in the `AbstractKeyValueMessageStore`
Add `SimpleMessageStore.clearMessageGroup()`
Accept polishing and fix `RedisChannelMessageStoreTests`
`@Deprecated` `MessageGroupStore.removeMessageFromGroup()`
Fix some typos
Introduce `SimpleMessageGroupFactory`
Extract `MessageGroupFactory` and address PR comments
Polishing after rebase
JavaDocs and Reference Manual
Fix JavaDocs
JIRA: https://jira.spring.io/browse/INT-3926
* Add `<poller>` for all `<outbound-adapter(gateway)>`
* Add/modify tests for `<queue>` as an input channel and particular `<poller>`
* Move XSD from the `xml` package to the `config` level to achieve the consistency throughout the project.
https://jira.spring.io/browse/INT-3665
Fixes according Travis report
Introduce `...ExpressionString(String)` setter
Some further fixes and polishing
Address PR comments
JIRA: https://jira.spring.io/browse/INT-3786
* Increase `receiveTimeout` for several `QueueChannel` and `CountDownLatch` based tests
* Fix `FileSplitterTests` for Windows compatibility - `UTF-8` for bytes conversion
* Make some STOMP tests as `LongRunning`
The next fixing phase
JIRA: https://jira.spring.io/browse/INT-3749
Since `IntegrationEvaluationContextAware` isn't so "context-free" resource like `BeanFactory`
and `ApplicationContext`, but just a specific bean in the context, we can't follow with `BeanPostProcessor` logic - bad architecture by level of responsibility.
Therefore we should follow with standard Dependency Injection mechanism to retrieve `evaluationContext` for the particular component.
Since we can't rely on the `@Autowired` because SI can be used from the raw XML configuration,
we use utility method instead. The pattern to get the proper `integrationEvaluationContext` is:
```
@Override
protected void onInit() throws Exception {
super.onInit();
this.evaluationContext = ExpressionUtils.createStandardEvaluationContext(getBeanFactory());
}
```
JIRA: https://jira.spring.io/browse/INT-3642
Currently, `removeMessageFromGroup` rebuilds the group on every removal.
In every case where this method is used in the framework, the result is not used.
Add `removeMessagesFromGroup` that removes a collection of messages and returns no result.
INT-3642: Polishing - PR Comments
INT-3642: Polishing and Fix Group Metadata Size
JIRA: https://jira.spring.io/browse/INT-3581
Move schemas to 4.2.
Add `selector-expression` to `<wire-tap/>`.
INT-3781: Fix What's New
Bump Namespace Version to 4.2
JIRA: https://jira.spring.io/browse/INT-3527
* `WebSocketInboundChannelAdapter` now handles `CONNECT` STOMP message and sends `CONNECT_ACK` message to the `WebSocketSession` immediately
* `ExpressionMessageProducerSupport` implementations now checks the result of `expression` and if it is a `Message<?>` it is sent to channel without creating a new one
which previously wrapped that `Message<?>` as the `payload`.
* Add `<script>` support to the `<outbound-channel-adapter>`
* Upgrade to the SF 4.1.1
* Add appropriate notes to the Docs
JIRA: https://jira.spring.io/browse/INT-3104
Add phase and remove unnecessary auto-starup
INT-3104: Remove reduntant code and format
Polishing and fixing parser tests
JIRA: https://jira.spring.io/browse/INT-3381
* Add support to mark `@Bean` methods with `Messaging Annotations`
* Addition attributes for `Messaging Annotations`
* Some refactoring and fixing
* Fix `AbstractMappingMessageRouter#onInit()` propagation
* Fix `GemfireGroupStoreTests` (https://build.spring.io/browse/INT-MASTERSPRING40-JOB1-246/test/case/135235772)
There is still some side effect: we need define `MessageChannel` beans explicitly. Since methods are processed within `BPP`,
not all beans with `Messaging Annotations` might be processed.
INT-3381: PR comments and other fixes
INT-3381 Polishing
INT-3381: Revert `RouterFB` & `SplitterFB`
JIRA: https://jira.spring.io/browse/INT-2738
Add a `getComponentType()` method for all handlers,
message producers, and message sources that implement
`NamedComponent` (see `SPCA.getComponentType()`).
Add rome as an optional dependency - STS complained
because AtomFeedHttpMessageConverter has a dependency
on it.
JIRA: https://jira.spring.io/browse/INT-3041
Add namespace support to simplify configuration of
a `RequestHandlerRetryAdvice.
INT-3041 Polishing; PR Comments
* Allow a retry-advice element within the request-handler-advice-chain
* Clean up schema (should not have allowed `synchronization-factory` on
the request-handler-advice-chain.
INT-3041 Polishing; PR Comment
This is still a work in process.
There are a bunch of TODOs in classes
that are not managed by Spring and so
need to have the MessageBuilderFactory
injected.
But I am looking for feedback on the
approach.
INT-3309 Resolve TODOs
Provide access to the MessageBuilderFactory in all classes.
INT-3309 Polishing + Tests
* Fallback to 'fromMessage()' if mutating and inbound message is not MutableMessage
* Add 'alwaysMutate' boolean to MutableMessageBuilderFactory - coerces 'fromMessage' calls to 'mutateMessage'
* Add tests
INT-3309 Polishing; PR Comments
Also add tests to parent/child contexts where the parent has the
default message builder and the child has a mutable message builder.
INT-3309 More Polish; PR Comments
Also fix removeHeader in MMB.
This commit updates Spring Integration to depend upon Spring 4, making
use of the message types that have moved from Spring Integration into
Spring's new spring-messaging module.
The default message converter no longer supports conversion of a
message that is null, throwing an IllegalArgumentException if an
attempt is made to convert null. Furthermore, GenericMessagingTemplate
does not support sending null, again throwing an
IllegalArgumentException. Previously, MessagingTemplate had no-oped an
attempt to send null.
ConcurrentAggregatorTests and AggregatorTests both had a single test
that was specifically testing the behaviour of an aggregator that
returns null for its message. These tests have been removed.
CorrelatingMessageHandlerTests have been updated to specify some
additional behaviour for its mocks so that null messages are not
returned.
These are the only functional changes that have been made. All other
changes are simply for moving to the repackaged and/or renamed types.
In the move to being part of core Spring, a number of constants and
header accessor methods have moved from MessageHeaders to
MessageHeaderAccessor. This commit continues this pattern for
the enterprise integration headers that are specific to Spring
Integration. A new class, EiMessageHeaderAccessor, has been created.
This class provides constants and methods for working with SI-specific
headers. The main code and tests have been updated to use this new
class.
