Commits on Aug 17, 2016
  1. @artembilan @garyrussell

    INT-4082: Fix MongoDB MessageStore for auditing

    Starting with Spring Data 1.9 the `MappingContextIsNewStrategyFactory` relies on a newly introduced `PersistentEntities` and doesn't register entities lazily any more.
    Such a change finishes with the `Unsupported entity` exception when an auditing is switched on (`<mongo:auditing/>`)
    for the `MongoDbMessageStore` and `AbstractConfigurableMongoDbMessageStore` internally created `MongoTemplate` and `MessageWrapper` and `MessageDocument` SI internal entities.
    * Don't register `ApplicationContext` into internally created `MongoTemplate`s since to avoid entity events emitting for `MessageWrapper` and `MessageDocument`
    * Pull `MongoDbMessageBytesConverter` to the top-level class to let customize `MappingMongoConverter` properly if there is need to audit `MessageDocument` anyway,
    what can be possible via external injections into `AbstractConfigurableMongoDbMessageStore` implementation
    * Fix `mongodb.adoc` for some typos
    **Cherry-pick to 4.2.x**
    artembilan committed with garyrussell Jul 28, 2016
  2. @artembilan @garyrussell

    INT-4087: Fix `tryLock(timeout)` Contract for ZK

    Fixes GH-1863 (spring-projects#1863)
    If ZK Client loses the connection to ensemble, it tries to reconnect on the next operation and does that exactly for the `connectionTimeoutMs` and provided `RetryPolicy`.
    According to the `Lock.tryLock(long time, TimeUnit unit)` contract we can wait for the lock only during provided `timeout`.
    * Introduce `mutexTaskExecutor` and perform `ZK.forPath()` command in the separate `Thread` and wait for the `Future` during provided timeout.
    * Perform `mutex.acquire()` only after successful `Future` result and only for the remained timeout.
    **Cherry-pick to 4.2.x**
    Add `setMutexTaskExecutor()`
    Fix Checkstyle typo
    artembilan committed with garyrussell Aug 16, 2016
  3. @artembilan
Commits on Aug 16, 2016
  1. @garyrussell

    INT-4097: Fix Test IMAP Mail Server

    Mismatched From/To headers when using a header mapper.
    garyrussell committed Aug 16, 2016
  2. @garyrussell

    Overview Doc Polishing

    garyrussell committed Aug 16, 2016
Commits on Aug 12, 2016
  1. @artembilan @garyrussell

    Some Fixes and Improvements

    * Fix several typos in log messages. And some test on the matter as well
    * Add comment to `AbstractPersistentAcceptOnceFileListFilter.rollback()` to clarify the reason of `rollingBack` variable
    * Make `RemoteFileTemplate.StreamHolder` as `static` to avoid extra internal variable to outer class instance
    * Replace `MessagingException` with `AbstractInboundFileSynchronizingMessageSource` in `init()` method of some components. It isn't Messaging yet in that phase
    * Fix `SubscribableRedisChannel.MessageListenerDelegate` to handle `Object` not `String`, because with the `serializer` injection there is no guaranty that incoming is always `String`
    * Move `JSch.setLogger(new JschLogger());` in the `DefaultSftpSessionFactory` to `static` block. It really should be done only once
    * Remove `Assert.isTrue(this.port >= 0)` from the `DefaultSftpSessionFactory`. The subsequant `initJschSession()` convert it to default `22` port
    * Change in the `JschProxyFactoryBean` `UnsupportedOperationException` to `IllegalArgumentException`. Wrong enum is wrong argument. That isn't a problem of operation
    * Simplify `stop()` in the `CuratorFrameworkFactoryBean` and mark it as a `this.running = false`. Otherwise it wasn't able to be restarted
    * Expose `leaderEventPublisher` in the `LeaderInitiatorFactoryBean`  and fix `stop(Runnable callback)` with propagation `callback` to delegate.
    Fix `SubscribableRedisChannelTests` for new `handleMessage(Object)` signature
    artembilan committed with garyrussell Aug 10, 2016
  2. @artembilan
Commits on Aug 10, 2016
  1. @artembilan
  2. @artembilan

    INT-4088 ZookeeperLeaderTests: fix race condition

    Two initiators for the same path, same `SmartLifecycleRoleController` and, finally, same `adapter`.
    So, one initiator after `yield()` stops the `adapter` and at the same time another starts it.
    Since there is no barrier in between events and assertion, we end up with an early "re-granting".
    * Add `CountDownLatch yieldBarrier` to `countDown()` after performing second `adapter.isRunning()` assert
    * `LeaderEventPublisher` waits for the `yieldBarrier` after the first `OnRevokedEvent`
    artembilan committed Aug 10, 2016
  3. @artembilan
Commits on Aug 9, 2016
  1. @garyrussell @artembilan
Commits on Jul 29, 2016
  1. @garyrussell @artembilan
  2. @artembilan
  3. @garyrussell
Commits on Jul 26, 2016
  1. @garyrussell @artembilan
  2. @artembilan

    INT-4078: Don't copy headers in the `Resequencer`

    Even if it doesn't hurt to `copyHeadersIfAbsent()`, when it just adds a new headers and doesn't override existing like sequence details,
    it doesn't sound reasonable for `Resequencer` to modify the message before and after its resequence logic.
    * Change `shouldCopyRequestHeaders()` to `false` for `ResequencingMessageHandler`
    artembilan committed Jul 26, 2016
Commits on Jul 25, 2016
  1. @artembilan

    build.gradle: Remove `java` plugin from the root

    To avoid extra empty `spring-integration-[VERSION].jar` from distribution remove `java` plugin usage from the root module of the project
    artembilan committed Jul 25, 2016
  2. @spring-buildmaster
  3. @spring-buildmaster
  4. @artembilan

    Upgrade to Spring AMQP 1.6.1

    artembilan committed Jul 25, 2016
  5. @vpavic @artembilan
  6. @garyrussell

    INT-4077: Increase Timeouts in JMS Test Case

    Default timeout (5 secs) is insufficient on a busy build server.
    garyrussell committed Jul 25, 2016
Commits on Jul 22, 2016
  1. @artembilan @garyrussell

    INT-4064: Simplify `IdempotentReInt` Java Config

    We configure `IdempotentReceiver` via `<int:idempotent-receiver>` component or `@IdempotentReceiver` annotation.
    In case of regular Java config, e.g. direct `ConsumerEndpointFactoryBean` usage or Java DSL,
    it isn't possible to configure `idempotentReceiverInterceptor` enough easy
    * Introduce `if...else` logic into `ConsumerEndpointFactoryBean` to proxy `MessageHandler`,
    if `adviceChain` contains an newly-introduced `HandleMessageAdvice`.
    And do that independently if `MessageHandler` is `AbstractReplyProducingMessageHandler`
    * Make `idempotentReceiverInterceptor extends HandleMessageAdvice`
    * Skip `HandleMessageAdvice` in the `AbstractReplyProducingMessageHandler`
    * Add advice applying logic into the `AbstractMethodAnnotationPostProcessor` as well
    Introduce `HandleMessageAdvice` marker interceptor to cover the case when an `Advice` can be advices as well.
    Remove unused `setAdviceChainIfPresent()` method in the `AbstractMethodAnnotationPostProcessor`
    Document `HandleMessageAdvice`
    Increase wait latch timeouts in the `LockRegistryLeaderInitiatorTests`
    Doc Polishing
    artembilan committed with garyrussell Jul 1, 2016
  2. @artembilan @garyrussell

    INT-4063: Extend Types for DefXmlPayloadConverter

    Since `DefaultXmlPayloadConverter` is used from many out-of-the-box components by default,
    make it more flexible with the supported input types which can be converted into `Document`
    Improve `xml.adoc` about this types and also fix a lot of typos there as well
    Address PR comments
    artembilan committed with garyrussell Jul 1, 2016
  3. @artembilan @garyrussell

    INT-4070: Fix @Gateway for Message Receive Style

    The `MessagingGatewaySupport.receive()` is fully based on the `this.messagingTemplate.receiveAndConvert(replyChannel, null);`
    which really just extracts `payload` from the `Message` via default `MessageConverter`.
    Therefore `@Gateway` code, which expects to poll exactly `Message<?>` from the flow, is invalid at runtime with `ClassCastException`
    * Expose `MessagingGatewaySupport.messagingTemplate` property as `protected` to give access for inheritors and siblings
    * In the `GatewayProxyFactoryBean` use `messagingTemplate` and `replyChannel` directly from the `MethodInvocationGateway`
    to invoke raw `gateway.messagingTemplate.receive(replyChannel)` bypassing any conversion and to avoid breaking changes.
    * Proof the solution with `GatewayProxyFactoryBean.testReceiveMessage()`
    **Consider to cherry-pick (backport) down to 3.0.x**
    Add `messagingGateway.convertReceiveMessage` global property to let revert to previous behavior
    * Make `messagingGateway.convertReceiveMessage=true` by default
    * Mock `BeanFactory` in the `GatewayProxyFactoryBeanTests.testReceiveMessage()`
    to be sure that `messagingGateway.convertReceiveMessage=false` works as expected
    * Add `testReceiveMessageConvert()` to demonstrate `ClassCastException`
    Rebase and make `convertReceiveMessage` integration property as `false` by default
    Introduce `MessagingGatewaySupport.receiveMessage()` and use it from the `GatewayProxyFactoryBean`
    artembilan committed with garyrussell Jul 13, 2016
Commits on Jul 21, 2016
  1. @artembilan @garyrussell

    INT-4072 Fix applySequence with State Propagation

    When `publishSubscribeChannel` is with `applySequence = true`, a `messageToSend` is overridden with `sequenceDetails` using `MessageBuilder`, therefore a new fresh `Message`.
    In case of state propagation, e.g. `SecurityContextPropagationChannelInterceptor`, we just lost the state from the `ThreadStatePropagationChannelInterceptor.MessageWithThreadState` because of new `Message<?>`
    * Add into `BroadcastingDispatcher` the logic to delegate `pushSequenceDetails` into `MessageWithThreadState` directly do not lose the `state`
    * Make `ThreadStatePropagationChannelInterceptor` as `MessageBuilderFactory`-aware and use it to rebuild an `original` `Message<?>` in the `MessageWithThreadState` to populate `SequenceDetails`
    **Cherry-pick to 4.2.x**
    Provide an explicit order for `publishSubscribeChannel` subscribers
    Fixes GH-1847 (spring-projects#1847)
    Fix mutation in the `ThreadStatePropagationChannelInterceptor`
    Since `BroadcastingDispatcher` invokes `pushSequenceDetails` for each subscribed handler,
    make `MessageWithThreadState` as immutable and return a new instance via `cloneWithSequenceDetails()` method with particular `sequenceDetails`.
    Previous mutable solution ended up with the issue of concurrent modification.
    * Introduce `CloneableMessage` abstraction to let any custom `Message` to return `MessageBuilder` with desired context.
    * Introduce `DelegatingMessageBuilder` as an extension of the `MessageBuilder` to let custom `CloneableMessage` to return desired customization.
    * Add into `MessageBuilder#fromMessage()` `if` for the `CloneableMessage`
    * Add into `MutableMessageBuilder` a `warn` about `CloneableMessage`
    * Revert changes in the `BroadcastingDispatcher` in favor of `CloneableMessage` in the `MessageBuilder`
    * Redo `ThreadStatePropagationChannelInterceptor#MessageWithThreadState` logic to be based on the `CloneableMessage` and `DelegatingMessageBuilder` extension.
    Introduce `MessageDecorator` contract
    Remove `CloneableMessage` aspect and everything around
    `MessageWithThreadState` is now `MessageDecorator` and `BroadcastingDispatcher` check if incoming `message` is `MessageDecorator` and performs its `decorateMessage` after `builder`
    artembilan committed with garyrussell Jul 13, 2016
Commits on Jul 20, 2016
  1. @artembilan @garyrussell

    INT-4075: Fix NPE in AbstractStompSessionManager

    Fixes GH-1854 (spring-projects#1854)
    The `catch` block just swallows an Exception with the logger and leaves `stompSessionListenableFuture` as `null`.
    The next `stompSessionListenableFuture` usage over two code lines bellow ends up with `NPE`.
    * Add reconnect logic into that `catch` block and just return from there, since we don't have anything to go ahead.
    * Add `if (e != null) {` around `log.error` in the `scheduleReconnect`
    * Add `if...else` around `this.stompClient.getTaskScheduler()` and `` to notify end-user that there won't be reconnection if there is no `taskScheduler`
    * Add `StompSessionManagerTests` mock tests to verify solution
    **Cherry-pick to 4.2.x**
    artembilan committed with garyrussell Jul 19, 2016
  2. @artembilan @garyrussell

    INT-4074 Late channel resolution for GatewayProxy

    If the `@ServiceActivator` component is processed first the application will start.
    However, if another component that relies on the channel creation goes first it'll fail as the bean for the channel does not exist.
    * Add `name` setters for all channels in the `GatewayProxyFactoryBean` to allow late channel resolution in the target `MethodInvocationGateway`
    * Change `MessagingGatewayRegistrar` to populate channel properties as names not bean references
    **Cherry-pick to 4.2.x**
    artembilan committed with garyrussell Jul 18, 2016
Commits on Jul 19, 2016
  1. @artembilan
Commits on Jul 14, 2016
  1. @artembilan
  2. @garyrussell

    Minor Doc Fix

    garyrussell committed Jul 14, 2016
Commits on Jul 11, 2016
  1. @artembilan @garyrussell

    INT-4067: Cover empty file case in `FileSplitter`

    When `FileSplitter` is configured with `markers = true` and file is empty, an `iterator` for file throws `IOException: Stream closed`,
    because we close the `buffer` just after the first `readLine()` attempt, but still return `true` from the first `hasNext()` call
    where the `this.sof` and `this.eof` are `true` for markers.
    Add logic to mark internal splitter `iterator` as `done` where we don't have content and still in `sof` state.
    artembilan committed with garyrussell Jul 7, 2016
  2. @artembilan @garyrussell

    INT-4013: `<ref bean>` for `channel-interceptor`

    Previously we couldn't define a config as :
    <int:channel-interceptor pattern="input*">
          <ref bean="sampleInterceptor" />
    * Fix `GlobalChannelInterceptorParser` to distinguish `BeanDefinitionParserDelegate.REF_ELEMENT` child elements
    and extract an appropriate `BeanReference`
    * Modify `GlobalChannelInterceptorTests-context.xml` to prove the fix and meet JIRA requirements
    artembilan committed with garyrussell Jul 1, 2016
  3. @artembilan @garyrussell

    INT-4057: Router: don't use convert for Class key

    When general router `channelKey` returns just a `Class<?>` result, we end up with the
    `unsupported return type for router [class java.lang.Class]` and forced to to call its `getName()` in the target application code before returning to router.
    * Change the `AbstractMappingMessageRouter` logic to treat `Class<?>` as a special String-aware case, use its `getName()` and don't go to the `ConversionService`
    * Increase receive timeout for replies in the `TcpInboundGatewayTests`
    artembilan committed with garyrussell Jun 15, 2016
  4. @garyrussell

    CLA Hook

    garyrussell committed on GitHub Jul 11, 2016