JIRA: https://jira.spring.io/browse/INT-3346
An `@Id` field is required when MongoDB auditing
is enabled in the ApplicationContext.
This change does not make the document Auditable,
it just prevents an exception being thrown when
auditing is enabled.
Also add another control-bus test.
Conflicts:
spring-integration-core/src/test/java/org/springframework/integration/config/xml/ControlBusTests.java
Resolved.
JIRA: https://jira.spring.io/browse/INT-3316
The `SimpleTypeConverter` delegate uses property editors
which are not thread safe. We protect against concurrent
access when the source is not a String, but when a String,
we delegate to the `STC`.
Synchronize access to the `STC.convertIfNecessary()` method.
JIRA: https://jira.springsource.org/browse/INT-3313
Previously, when `requires-reply="false"` on a `<jms:outbound-gateway/>`
a `null` reply caused a `MessageTimeoutException`, instead of quiet ending of flow.
Conflicts:
spring-integration-jms/src/test/java/org/springframework/integration/jms/JmsOutboundInsideChainTests.java
Resolved.
JIRA: https://jira.springsource.org/browse/INT-3305
Previously, if the channel can't be connected (e.g. if the server
does not support SFTP), the connection to the server remained open.
Close the session in the event of a failure.
Add test with the Apache SSHD server.
JIRA: https://jira.springsource.org/browse/INT-3298
Emit a WARN log whenever the `ReleaseStrategyFactoryBean`
falls back to using the `SequenceSizeReleaseStrategy`.
This will happen if no method name is provided and no
annotated method is found, or a null reference is provided.
https://jira.springsource.org/browse/INT-3310
Previously, the syslog adapter tried to convert the ErrorMessage
that results from a socket error to a syslog packet, resulting
in a stack trace on stderr.
Test for the ErrorMessage and log at DEBUG.
JIRA: https://jira.springsource.org/browse/INT-3300
The change introduced by https://jira.springsource.org/browse/INT-3147
(Registration of `MessageSource<?>` as a bean with suffix `.source`) broke
the case where `MessageSource<?>` is a reference to an existing bean.
Add check to the `AbstractPollingInboundChannelAdapterParser` for the type
of `source` and apply the appropriate logic.
Conflicts:
spring-integration-core/src/test/java/org/springframework/integration/config/ChannelAdapterParserTests.java
Resolved.
ByteArraySingleTerminatorSerializer does not support multiple
subsequent terminators (zero length messages).
JIRA: https://jira.springsource.org/browse/INT-3290
* Add unit test to verify bug.
* Fix bug.
Polishing:
* Remove test for `n >= 0`; n cannot be < 0 here
* Move test case to `DeserializationTests`
JIRA: https://jira.springsource.org/browse/INT-3285
Spring Integration 3.0 introduced the `JsonHeaders` and populates them
from a request AMQP Message to the SI Message. In the case of the `AmqpInboundGateway` and
`JsonMessageConverter`, if the SI flow doesn't do anything with `JsonHeaders`
they are returned to the `AmqpInboundGateway` for reply Message
and may override correct values provided by `JsonMessageConverter` in the `DefaultAmqpHeaderMapper`.
This fix provides the check for headers from the reply Message's `MessageProperties`
and populates `JsonHeaders` if the `MessageProperties` doesn't contains the `__TypeId__` header already.
Note, it is just a fix for regression to restore previous behavior.
There is maybe a reason to revise (Another JIRA) all standard AMQP headers and populate them from SI `MessageHeaders`
in the `DefaultAmqpHeaderMapper`, only if they haven't been populated by `MessageConverter` before.
**Cherry-pick to 3.0.x**
Conflicts:
spring-integration-amqp/src/test/java/org/springframework/integration/amqp/inbound/InboundEndpointTests.java
Resolved.
JIRA: https://jira.springsource.org/browse/INT-3243
* Change `IntegrationRequestMappingHandlerMapping` to postpone
Handlers detection as late as possible using `ApplicationListener<ContextRefreshedEvent>`.
This is needed, because `RequestMappingInfoHandlerMapping#afterPropertiesSet()`
iterates over beans from the `BeanFactory` to detect MVC Handlers. But at the same time
Integration Endpoints require a `requestChannel` as a dependency and those may be postponed
for `auto-creation` by `ChannelInitializer` - late-binding issue.
JIRA: https://jira.springsource.org/browse/INT-3274
* Add condition on `springVersion` to check `BUILD-SNAPSHOT` release category on version
and enable `libs-snapshot` repository
To allow CI plan to build with SF snapshots it's just enough to configure the Gradle option
`-PspringVersion=3.2.7.BUILD-SNAPSHOT`
- ((CachingSessionFactory<?>.CachedSession) session).dirty();
+ ((CachingSessionFactory.CachedSession) session).dirty();
Failed to compile with Java6 (compiles ok with Java7 with
sourceCompatibility=1.6).
If an exception occurs on a session it should be physically closed
and not reused because its state is indeterminate and the next
operation might fail.
Note: The booleans within CachedSession do not need to be volatile
because it is a short-lived object only used by the current thread.
Also fixes the assertion message in RFT.get().
JIRA: https://jira.springsource.org/browse/INT-3266
INT-3266 Polishing - PR Comments
Remove need for SuppressWarnings.
Fix 2 test cases where the exception has an additional cause.
Fix invalid `GenericMessage` import
Fix `e.getCause()` in `FtpServerOutboundTests` & `SftpServerOutboundTests` tests
Set up stored procedure name in `SimpleJdbcCall` before setting
up row mappers; previously the debug logg showed `[null]` for
the procedure name.
JIRA: https://jira.springsource.org/browse/INT-3265
JIRA: https://jira.springsource.org/browse/INT-3252
Remove the use of `SecureRandom.generateSeed()` which is not
supported on some platforms.
Note: While this change does not reflect the custom IBM
code noted in the JIRA issue, it does revert the initial
SecureRandom generation to use the same code as
UUID.randomUUID(), so the expectation is that this will
work fine on zOS.
JIRA: https://jira.springsource.org/browse/INT-3240
Spring Integration 3.0 introduced registration of `MessageSource`s as beans
with an `id` based on the adapter `id` or, as a fallback, generated from
the `MessageSource` class name and the suffix `.source`.
But since that bean wasn't registered as a bean with the generated name (because the suffix was added),
subsequent elements get the same source bean name. This meant that
several anonymous `inbound-channel-adapter` with the same type (`file:`, `ftp:`, `twitter:` etc.)
caused an issue, when the same `MessageSource` bean was used by several `SourcePollingChannelAdapter` beans.
Fix the issue for fallback name generation by using the `SourcePollingChannelAdapterFactoryBean` class name.
Since that is registered, the source will always get a unique name, regardless of whether an id is provided.
Remove warning from BFCR if there is no HeaderChannelRegistry in
the bean factory. Change the log to DEBUG and remove the stack
trace.
Instead, update the Exception message when a channel name can't be
resolved to a channel to indicate that there is no registry.
JIRA: https://jira.springsource.org/browse/INT-3248
JIRA: https://jira.springsource.org/browse/INT-3149
* Add a note about `GatewayMethodMetadata`
* Squash several sections to one by type
* Reorder by importance/interestingness
* Remove a note about `MessagingException` for `RetryAdvice`,
as the last one doesn't wrap exceptions to `MessagingException` on each retry
JIRA: https://jira.springsource.org/browse/INT-3235
Unable to programmatically wire header expressions or method-specific
properties into a GatewayProxyFactoryBean.
The GPFB has public methods that take arguments of
this type.
Make the class public instead of package-protected.
Add a test case.
JIRA: https://jira.springsource.org/browse/INT-3233
With Windows 7 and Java 7/8 closing a server channel does
not close the underlying socket. Closing the Selector does
close the socket.
It is not clear why this is needed, given that a selector can
be used for multiple sockets.
However, we only use the server side selector for a single
server socket so there is no detriment in closing it.
Also close the selector on the client side (even though it is
used for multiple sockets, because we are stopping the factory
anyway and all sockets will be closed).
However, closing the selector opens us up to 'ClosedSelectorException's
in several places. Add catch blocks to deal with this exception, and only
log an error if the factory is active.
While debugging this issue, I found that a number of (older) tests
left threads running, sockets open etc.
INT-3233 Polishing - PR Comments
JIRA: https://jira.springsource.org/browse/INT-3232
Previously, in the `RedisQueueMessageDrivenEndpoint` all `Exceptions` on `rightPop` operation
were logged with `error` level independently of the state of the Endpoint.
Add `if...else` and log with `debug`, if the Endpoint isn't active and don't publish the event.
JIRA: https://jira.springsource.org/browse/INT-3223
Don't use primitives in Tail factory bean setters so that the placeholders
for attributes that force the Apache implementation can resolve to "".
Test for an empty string in native-options and don't set.
