JIRA: https://jira.spring.io/browse/INT-3565
Cast to `IntegrationObjectSupport` fails if the handler is
already proxied in `AbstractSimpleMessageHandlerFactoryBean`.
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/config/AbstractSimpleMessageHandlerFactoryBean.java
Resolved.
INT-3565 Polishing
- Fix test.
- enhance test to show that directly bound message handler beans are not advised if already proxied.
JIRA: https://jira.spring.io/browse/INT-3545
Previously, the `DefaultHeaderChannelRegistry` was auto-started.
This caused the reaper to run and eventually start all the
`taskScheduler` threads, even if the registry was not being used.
- Defer the `start()` until the first channel is stored.
- Do not start the reaper if the bean has been explicitly stopped.
- Deprecate the implementation of `SmartLifecycle`.
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/channel/DefaultHeaderChannelRegistry.java
Resolved.
__cherry-pick to 3.0.x__
JIRA: https://jira.spring.io/browse/INT-3543
Quoting Sam Brannen:
> However, one should *never* programmatically close the injected application context in a test,
since the Spring TestContext Framework caches all contexts across the entire JVM process.
If you need to close a context after a test method or test class for some reason,
the only supported and reliable mechanism is `@DirtiesContext`.
**Cherry-pick to 4.0.x**
JIRA: https://jira.spring.io/browse/INT-3539
Previously the `ChannelSecurityInterceptorBeanPostProcessor` eagerly loaded all beans from its `afterPropertiesSet`
to retrieve the `ChannelSecurityInterceptor`s. According to the `BeanPostProcessor` nature the `afterPropertiesSet` hook isn't legitimate.
It may cause some bad side-effects for other beans, which might not been initialized yet.
Rework `ChannelSecurityInterceptorBeanPostProcessor` to accept `Collection<ChannelSecurityInterceptor>` in the ctor.
Rework `SecurityIntegrationConfigurationInitializer` to iterate over `BeanDefinition`s to determine those of them, which
are `ChannelSecurityInterceptor` or `ChannelSecurityInterceptorFactoryBean`.
**Cherry-pick to 4.0.x**
JIRA: https://jira.spring.io/browse/INT-3536
The fix for opening multiple IMAP connections in the idle
adapter inadvertently removed the check for the store being
open.
Add `connectStoreIfNecessary()` and test case.
JIRA: https://jira.spring.io/browse/INT-3528
Use `min` and `max` methods instead of sorting an entire collection to get the minimum or maximum element.
Change other inline `Comparator<?>`s to the `final` fields
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/aggregator/AbstractCorrelatingMessageHandler.java
JIRA: https://jira.spring.io/browse/INT-3526
Previously, the URI in the exception message is the raw
URI with placeholders, if present.
Use the expanded URI in the message instead.
(cherry picked from commit 113716e)
JIRA: https://jira.spring.io/browse/INT-3524
Backport to 4.0 schemas.
A number of references (expected-type) still referred to
the Spring Integration 3.0 MessageChanel.
JIRA: https://jira.spring.io/browse/INT-3510
There has been an error in schema creation scipt for message store on postgresql database:
The statement for creating sequence 'INT_MESSAGE_SEQ' was executed AFTER creating the table that actually uses this sequence
which resulted in sequence not found error.
Further problem was that the the corresponding index 'MSG_INDEX_DATE_IDX' in creation script does not match the index name
'INT_CHANNEL_MSG_DATE_IDX' in drop script. Therfore an error occurred when executing drop schema script for postgresql.
Fixes:
1.Moved creation of sequence 'INT_MESSAGE_SEQ' to first line to be executed before creating the corresponding table
2.Renamed index 'MSG_INDEX_DATE_IDX' to 'INT_CHANNEL_MSG_DATE_IDX' in create script to make drop script work again
On branch INT-3510
JIRA: https://jira.spring.io/browse/INT-3501
There were several problems:
When a `Folder` is open, an activity on the `Store` opens a new
connection.
The `PingTask` called `isConnected()` on the store, creating a new
connection. The pings (NOOPs) were performed on this connection and
therefore did NOT cancel the `IDLE`.
In any case, the `IDLE` was issued on the folder not the store and
the only way to cancel that IDLE is to cause its `waitIfIdle()` to
be invoked. Conveniently, simply calling `isOpen()` invokes that
method and cancels the IDLE.
Finally, the `SimpleMessageCountListener` unnecessarily invoked
`message.getLineCount()` when a simple `folder.isOpen()` is
sufficient.
Fixes:
1. Do not invoke `openSession` if `this.folder` is not null.
2. Change the `PingTask` to simply invoke `isOpen()`.
3. Move the `PingTask to the receiver for a more efficient algorithm
instead of running on fixed interval. Rename it `IdleCanceler`.
4. Increase the PING timer from 10 to 120 seconds; add setters for it
and the `reconnectionDelay`.
TODO: Namespace support for 4.1. (Not to be back ported).
Add a test IMAP server (ported from Java DSL and enhanced to simulate IDLE
with a new message arriving for the first idle period.
INT-3501 Polishing - PR Comments
Polishing for `PoorMansMailServer` to get rid of `smtp` and `pop3` servers to avoid unnecessary Base64 dependency
JIRA: https://jira.spring.io/browse/INT-3499
- Suppress (log) 'null' payload error when no correlation data
- Change tests to use a dedicated template for confirms/returns
Conflicts:
spring-integration-amqp/src/test/java/org/springframework/integration/amqp/config/AmqpOutboundChannelAdapterParserTests.java
src/reference/docbook/amqp.xml
Resolved.
JIRA: https://jira.spring.io/browse/INT-3470
According to the commit https://github.com/spring-projects/spring-framework/commit/c06ac06,
the `MessagingException` is now `NestedRuntimeException` including nested StackTrace.
Hence test-cases have to be changed to the `Mathers.containsString` instead of `equals` for the `e.getMessage()`
**Cherry-pick to the 4.0.x**
Conflicts:
spring-integration-amqp/src/test/java/org/springframework/integration/amqp/channel/DispatcherHasNoSubscribersTests.java
spring-integration-core/src/test/java/org/springframework/integration/handler/advice/AdvisedMessageHandlerTests.java
JIRA: https://jira.spring.io/browse/INT-3464
Previously, if an IO exeption occurred while synchronizing
files, and an AcceptOnceFileListFilter is being used, files that were
not transferred would not be fetched next time.
Add strategy `ReversibleFileListFilter` that can rollback previously
accepted files.
Implement this interface on `AcceptOnceFileListFilter` and
`AbstractPersistentAcceptOnceFileListFilter`.
Add test cases.
Polishing
JIRA: https://jira.spring.io/browse/INT-3474
When the MethodInvokingMessageHandler skips ineligible methods while
searching it emits a stack trace under DEBUG logging. This is not
needed, a simple log message is enough to convey the information.
Some POJOs gain ineligible methods when wrapped in a proxy so this
is no fault of the developer.
Other reasons for skipping methods (improperly set annotations etc)
continue to emit a stack trace.
INT-3474: Polishing
Rethrow `IneligibleMethodException` as `IllegalArgumentException` in case of a single `method` for processor
JIRA: https://jira.spring.io/browse/INT-3473
A simple fix to prevent `Selector closed` error loging message on `TcpNioServerConnectionFactory#stop()`
Polishing
JIRA: https://jira.spring.io/browse/INT-3470
* Apply the last `ChannelInterceptor` changes - just `extends ChannelInterceptorAdapter`
* Change some tests to check content according to the new changes to the `GenericMessage#toString()`
**Cherry-pick to 4.0.x**
JIRA: https://jira.spring.io/browse/INT-3469
Previously, the callback was set immediately after
subscribing which caused a small possibility of
message loss.
Set the callback before subscribing.
JIRA: https://jira.spring.io/browse/INT-3448
INT-3448: Addressing PR comments
Late Resolution of @Publisher.defaultChannel
Early resolution of the publisher default channel caused
`@ Configuration` factory beans to be instantiated before
Spring Integration bean post processors had been registered.
Use the channel name instead of channel reference and resolve
it when processing the first publish.
Merge branch 'INT-3448' of https://github.com/garyrussell/spring-integration into INT-3448
Conflicts:
spring-integration-core/src/test/java/org/springframework/integration/configuration/EnableIntegrationTests.java
INT-3448: Polishing
JIRA: https://jira.spring.io/browse/INT-3461
To test it: `gradlew :spring-integration-http:testAll -PspringVersion=4.1.0.BUILD-SNAPSHOT`
INT-3461: Add CP condition for `rometools` into the `HttpRequestHandlingEndpointSupport`
INT-3461: Add CLASSPATH check for `RequestEntity` to determine the SF 4.1
Conflicts:
build.gradle
Resolved.
JIRA: https://jira.spring.io/browse/INT-3458
* Change Spring AMQP to `1.3.5.RELEASE`
* `HttpRequestHandlingEndpointSupport`: remove `MappingJacksonHttpMessageConverter` registration
* `IntegrationRequestMappingHandlerMapping`: add 'fake' `name()` attribute to the inline `RequestMapping` annotation
* `StoredProcJmxManagedBeanTests`: remove `context.stop();` code, Since `MBeanExporter` deregister MBeans on `stop()` now
* `StoredProcPollingChannelAdapterParserTests`: change deprecated `ParameterizedSingleColumnRowMapper` to the `SingleColumnRowMapper`
* `Jms`: comment out the reflection code to check the value for the `recoveryInterval`, because it is removed already in favor of `backOff`
* `NotificationListeningMessageProducer`: move the start-up listener registration to the `onApplicationEvent`,
because `MBeanExporter` moved `registerBeans()` to the `start()` now.
The same `phase` might cause the issue, that MBeans aren't registered yet for `NotificationListeningMessageProducer`
* `JpaOutboundGatewayTests`: change `@TransactionConfiguration` to the `@Transactional`. Don't know why the first doesn't work now.
**Cherry-pick to 4.0.x**
INT-3458: Addressing PR comments
`NotificationListeningMessageProducer`: defer listener registration until `onApplicationEvent()`
Conflicts:
build.gradle
Resolved.
Fixed hung assembler described in INT-3453.
Used CountDownLatch instead of sleep()
INT-3453 Add Test Case
Currently failing for me - assembler thread stuck on CDL.
Remove redundant `if (TcpNioConnection.this.writingLatch != null)` from `ChannelInputStream#write`
JIRA: https://jira.spring.io/browse/INT-3433`
If a read fails due to insufficient threads, delay the read
for (default 100ms) - do not re-enable OP_READ until that
time has elapsed. Avoids spinning the CPU.
INT-3433 More Polishing
If the assembler couldn't execute a new assembler after assembling
the current message (when it detected there is more data), in the
finally block it would "continue" only if the socket was still
open.
The test case closes the socket after sending 4 messages so when
this condition occurred, the assembler failed to continue and
data was left in the buffer.
Remove the `isOpen()` check in the finally block and always continue
if there's not another assembler running and there's data available.
INT-3433 More Polishing
We can still get starvation if the selector is in a long
wait (in select()) when a read is delayed.
Whenever a read is delayed, wake the selector so its next
select will use the readDelay timeout.
INT-3433 Reference Docs
Also remove Thread.yield().
Revert redundant boolean return from `TcpNioConnection#checkForAssembler()`
