Depending on timing, it was possible the event the test
case was waiting for would never happen. With no timeout
the selector will block until the next IO event occurs,
and there is none in this test.
Adding a call to factory.close() forces a wakeup of
the selector, which will force the harvest to occur.
This is a test-only problem.
When using NIO, a Map of connections is maintained (keyed
by the SocketChannel) and used to manage registrations
for NIO events, timeouts etc.
When a connection is closed, the corresponding entry
should be removed from the map. The code to do this
is in AbstractConnectionFactory.processNioSelections().
However, if no socket timeout (soTimeout) has been set,
or it was explicitly set to 0, connections are not
removed from the map. This was because the timeout
logic and map cleanup is done in the same iteration
loop.
Now, if soTimeout is not set, the clean up loop
operates every nioHarvestInterval milliseconds
(default 2000), we don't want to run it on
every selector event.
In addition, it runs if the selectionCount is
zero - this might occur when a socket
is closed, when the selector.wakeup() is called.
XPathHeaderEnricherTests#notSkippingNullValues() add 'enricher.setDefaultOverwrite(true);' as right behavior for overwriting on existing headers
INT-2405 fix MessageProcessor for <header-value>
1. MethodInvokingHeaderValueMessageProcessor => MessageProcessingHeaderValueMessageProcessor because now he uses MessageProcessor
2. polishing HeaderEnricherParserSupport
3. GroovyHeaderEnricherTests: add check to HeaderValueMessageProcessor for Groovy scripts.
4. build.gradle: add dependency to 'spring-integration-test' for 'spring-integration-groovy'.
5. Fix HeaderEnricherParserSupport like in INT-2188
1. MethodInvokingHeaderValueMessageProcessor => MessageProcessingHeaderValueMessageProcessor because now he uses MessageProcessor
2. polishing HeaderEnricherParserSupport
3. GroovyHeaderEnricherTests: add check to HeaderValueMessageProcessor for Groovy scripts.
4. build.gradle: add dependency to 'spring-integration-test' for 'spring-integration-groovy'.
5. Fix HeaderEnricherParserSupport like in INT-2188
PubSub channel subscriber accounting was incorrect; the counter
was not decremented when unsubscribing.
The handler count, reflecting the current number of subscriptions,
was maintained in the AbstractSubscribableChannel. The count really
belongs in the dispatcher and calls should be delegated to it, particularly
for a custom ASC, which might have a custom AbstractDispatcher.
However, it is possible (although perhaps rare) that someone
could implement a custom channel with a custom dispatcher that
is *not* a subclass of AbstractDispatcher.
Therefore, we now delegate to the dispatcher if we can, and
revert to a counter in the channel if we can't.
Also, the asymmetric accounting in this case is resolved; the
counter is decremented when a subscriber unsubscribes.
Polishing - factor out common code.
Fixed DefaultSftpSessionFactory#OptimisticUserInfoImpl to additionally implement UIKeyboardInteractive, tested with both right and wrong password.
Cherry pick; fix copyright.
Fix PollerParser#configureAdviceChain for adding 'customBeanDefinition' into 'adviceChain' List.
PollerParserTests: adding <tx:advice> as customElement into poller's <advice-chain>.
ServiceActivatorFactoryBean#createMessageProcessingHandler: force 'processMessage' method-name parameter into constructor ServiceActivatingHandler for MessageProcessor
Test for check 'handlerMethods' in ServiceActivatingHandler's MethodInvokingMessageProcessor
Integration test for <service-activator> with invalid Groovy inline script
JMS backed channels can have container-type and
container-class. Parser rejected container-class because
the schema has a default for container-type.
Both attributes are allowed; user must set container-type
appropriately (based on the superclass of the custom class)
when container-class is provided.
* MessageChannel was moved from core to the base package.
* ChannelResolver moved from core to support.
* TcpConnectionInterceptorFactoryChain was incorrect.
Backport to 2.0.x
upgraded spring framework dependency to 3.0.7.RELEASE
upgraded spring security dependency to 3.0.7.RELEASE
upgraded spring ws dependency to 2.0.3.RELEASE
added exclusions for spring-ws transitive dependencies
updated etag test for spring 3.0.7
Mac OSX problem was encountered only on the client; similar
code exists on the server side, so the workaround should
be implemented there too; just in case.
If a tcp client connection factory was configured for single-use
connections (one socket per message), and it was used by an outbound
channel adapter (send and forget), the socket is closed immediately
after sending the message.
This could cause issues with the connection handling because certain
failures could occur. For example, the close could occur before we
ever registered the channel for read selection, resulting in a
ClosedChannelException. Secondly, there was a small timing hole
where a selection key could be invalidated between the isValid()
call and isReadable().
These problems have been corrected.
polished MethodInvokingMessageProcessor constructor that takes boolean argument by renaming the argument from 'requiresReply' to 'canProcessMessageList' which is what it really maps to in MessagingMethodInvokerHelper.HandlerMethod
fixed 'filterSelectsNonVoidReturningMethodsOnly' and 'testOverloadedNonVoidReturningMethodsWithExactMatchForType' tests of MethodInvokingMessageProcessorTests to invoke the right constructor and commented out 'testVoidMethodsExcludedByFlag' test as its no longer valid
Added support for recognizing default components in parent ApplicationContext before they get auto-registered in child AC
Added containsBean check earlier, removed 'IfNecessary' from method names
