Delegating consumer endpoints (<service-activator/> etc)
may not have both 'expression' and 'ref' attributes.
Previously, 'expression' was ignored when 'ref' was present.
- Enforce mutual exclusivity in AbstractDelegatingEndpointParser.
- Add tests for illegal combinations.
- Improve error message when 'method' used with <expression/>.
- Change parser to use reader.error() instead of Assert.
- Add element description to all parser errors.
Gradle may run tests using multiple threads.
Using shared resources (e.g. `System.out`) may produce concurrency issues.
* Remove usage of `System.out`
* Add mocking around `LoggingHandler#messageLogger`.
JIRA: https://jira.springsource.org/browse/INT-2880
Documentation indicates that the keystore and truststore
arguments can be resource patterns (file:..., classpath:..., etc)
but the code always used a ClasspathResource.
Use a PathMatchingResourcePatternResolver to interpret the
pattern correctly.
Add tests.
Heretofore there wasn't ability to make some scenario like this, when we want to make failure notification on each retry:
<service-activator>
<request-handler-advice-chain>
<bean class="org.springframework.integration.handler.advice.RequestHandlerRetryAdvice"/>
<bean class="org.springframework.integration.handler.advice.ExpressionEvaluatingRequestHandlerAdvice"
p:onFailureExpression="#exception" p:failureChannel-ref="errorOnEachRetryChannel"/>
</request-handler-advice-chain>
</service-activator>
The second Advice was invoked only once. This was because `ProxyMethodInvocation` keeps the index of current interceptor
on each `invocation.proceed()`, which is recursive by design.
So, change `AbstractRequestHandlerAdvice` to use `((ProxyMethodInvocation) invocation).invocableClone().proceed();`
This way, we get a fresh `MethodInvocation` for the current `Advice` with nested desired advices.
JIRA: https://jira.springsource.org/browse/INT-2858
INT-2858: Polishing; PR Comments
Introduce `AbstractRequestHandlerAdvice.ExecutionCallback#cloneAndExecute()` especially for repeatable Advices, e.g. `RequestHandlerRetryAdvice`
to avoid overhead from `clone()` on simple Advices
INT-2858: Doc ExecutionCallback#cloneAndExecute()
INT-2858 Polishing
Rework docs; add Javadoc; add to test case.
- allow the configuration of release strategies on resequencers
-- adjust the xsd to allow the definition of a release strategy
-- move release strategy parsing to AbstractCorrelatingMessageHandlerParser
-- add unit tests
For reference see: https://jira.springsource.org/browse/INT-2863
INT-2863 Polishing
Fix white space; add @author; update copyright.
INT-2863 Resequencer/Aggregator Docs
Add docs for correlation and release strategis to Resequencer.
Add *.expression docs to Aggregator.
In many cases IDEs import into test configs Namespace-resources
with hardcoded versions of Spring & Spring Integration XSDs.
This may produce build issues with different Spring versions.
It also causes an issue during the transition to a new Spring Integration version (e.g. 3.0).
* Add Gradle task 'checkTestConfigs' to check test configs for hardcoded resources' versions.
* Add to 'test' task dependency on new task 'checkTestConfigs'
* Fix hadrcoded versions in the test configs.
JIRA: https://jira.springsource.org/browse/INT-2845
In Spring 3.1, DefaultResponseErrorHandler.getResponseBody() is
tolerant of a null InputStream on the response. With Spring 3.0
a null response causes an assertion exception.
The mock in the tests was not set up to return an InputStream
and so the test failed when building with Spring 3.0.
Configure the mock to return an empty InputStream.
Also added a text response to response.getStatusText().
Tested with Spring 3.0 and 3.1.
Expire empty groups.
Due to indentation changes, the code changes look more extensive
than they are. In effect the if (group.size() > 0) test is moved
to a narrower scope and the remove(group) is now performed if the
group is empty.
Document expire-groups-upon-completion.
INT-2832 Doc Polishing
PR Review + punctuation.
INT-2833 Add Delay For Expiring Empty Groups
minimumTimeoutForEmptyGroups
When the expected-response-type was Serializable,
no Accept: header was added.
The SerializingHttpMessageConverter overrides
canRead() from the superclass.
The superclass method allows null in the mediaType
parameter to return true. RestTemplate.AcceptHeaderRequestCallback
calls canRead() with null in the mediaType, preventing
the Accept header from being completed.
Remove the overridden method.
INT-2837 Disable Java Serialization over Http
Previously, Java serialization was enabled by default by
adding the SerializingHttpMessageConverter to the converter
lists (inbound and outbound endpoints). However, there was
a problem in that the Accept header was not set properly on
outbound requests.
Correcting the header could cause other side effects, such as
existing JSON applications using Java serialization instead.
It was felt that it would be safest to disable Java serialization
by default, while retaining the ability to use Java serialization
by explicitly configuring the message converter.
Update tests to deal with the fact the converter is not
configured by default.
INT-2837 Fix Schema Version in Test
Inadvertently added a spring 3.1 schema version.
A secondary part of the new gateway test was to ensure we
reused the cached connection. However, there was a race condition
in that the connection may not yet have been returned to the pool
by the reader thread that received the response.
Using the CachingClientConnectionFactory with a gateway
doesn't work. The Listener (gateway) was not being set up
properly by the wrapper. Instead, the actualListener in the
wrapped connection was set to null. This caused the connection
to "close" itself (return to the pool) immediately after the send.
In addition, even with the actualListener set up to properly
reference the gateway, it still wouldn't work because the
gateway can't correlate the reply (the cached connectionId is
prefixed with "cached:" so the gateway can't find the reply.
Further, when onMessage() returned, it caused the reader loop
to end.
Fixes:
1. Properly set up the cached connection with the real listener
so that ultimately the underlying connection sees there is an
actualListener and so doesn't close itself after the send.
2. Override getListener() on the cached connection to return the
real listener.
3. Override onMessage() in order to fix up the connection id in
the message, and return true (intercepted) so the connection doesn't
close itself (terminate the reader thread).
4. close() (return to the pool) after invoking the gateway's
onMessage().
5. Add test cases to verify proper operation including an assertion
that the pooled connection is reused.
This is made a little more complex by the tangle between
connections and connection interceptors; mainly because single-use
connections close themselves after use. This will be addressed in
3.0 (INT-2829) making connection interceptors simpler.
* Remove Class Tangle in JPA
* tcp.connection
* tcp.connection.support
* Add Comment to MessageGroupCallback
- Comment that it is moving into MGS in 3.0.
- Convert DOS newlines to Unix.
For reference see: https://jira.springsource.org/browse/INT-2828
Recent changes to APE were sub-optimal because the subclasses
had to call back into the parent abstract class.
Deprecate doPoll() on APE.
Introduce a temporary intermediate abstract class that supports
transaction synchronization.
This class will be deprecated in 3.0.0 when its methods will
be pulled up into APE.
INT-2815 Polishing
Make ATSPE package visibility.
Add helpers to enable early migration to 3.0 structure.
INT-2815 Polishing
Fix javadoc to emphasize that doPoll() will no longer
be overridable in 3.0.
Rename doReceive() to receiveMessage() to match more closely
with handleMessage().
INT-2815 Polishing
Fix message in UnsupportedOperationException.
