JIRA: https://jira.spring.io/browse/INT-3705
* Add validation for annotation attributes which must be populated directly on the `MessageHandler` `@Bean` using setters
* Add `sendTimeout()` annotation attribute for all Messaging Annotations
* Remove `DEFAULT_SEND_TIMEOUT = 1000L` from `AbstractCorrelatingMessageHandler` to make its component consistent with all other
`AbstractMessageProducingHandler` implementation.
* Fix XSD docs and Reference Manual to say that default `send-timeout` for `AbstractMessageProducingHandler` components is `-1`, not `one second`
* Make all Messaging Annotations attributes as `String` to allow to configure through the Property Placeholder options
* Fix a couple of typos
Polishing
JIRA: https://jira.spring.io/browse/INT-3704
Some NoSQLs (e.g. Hazelcast) provide a distributed implementations for the `ConcurrentMap`,
so add `SimpleMetadataStore(ConcurrentMap<String, String> metadata)` to allow ot inject any `ConcurrentMap` implementation.
Demonstrate the support for Hazelcast in the `IdempotentReceiverIntegrationTests`
**Cherry-pick to 4.1.x**
JIRA: https://jira.spring.io/browse/INT-3700
Change to calculate proper syndicate entry date for comparison when
adding feeds for processing.
I have signed and agree to the terms of the SpringSource Individual
Contributor License Agreement.
unit test for recent changes to FeedEntryMessageSourceTests to verify
proper last seen date calculation.
updates for comments from code review
* newline at EOF on atom.xml
* removed question from code
* fetch files via classpath instead of file system
* 'else' on newline
* authorship on class
Polishing
JIRA: https://jira.spring.io/browse/INT-3698
The `HttpRequestExecutingMessageHandler` added two internal `Converters` to the `ConversionService` before.
In case of parent-child environment it causes memory leak: closing of child context doesn't release
`HttpRequestExecutingMessageHandler` instances, because those internal `Converters` aren't `static`, hence bounded to outer instance.
Actually after introduction since `4.0` version to the `HttpRequestExecutingMessageHandler` the code like:
```
Assert.isTrue(expectedResponseType instanceof Class<?>
|| expectedResponseType instanceof String
|| expectedResponseType instanceof ParameterizedTypeReference,
"'expectedResponseType' can be an instance of 'Class<?>', 'String' or 'ParameterizedTypeReference<?>'.");
if (expectedResponseType instanceof String && StringUtils.hasText((String) expectedResponseType)){
expectedResponseType = ClassUtils.forName((String) expectedResponseType, ClassUtils.getDefaultClassLoader());
}
```
These converters are redundant.
In addition remove the `expected type` for the `uriVariablesExpression` evaluation to avoid `MapToMapConverter`.
**Cherry-pick to 4.1.x, 4.0.x**
INT-3698: Provide robust logic for the `uriExpression` and `httpMethodExpression`
Make some polishing around `Assert`s, when `IllegalStateException` must be presented instead of `IllegalArgumentException`
for the expression evaluation results.
Polishing
JIRA: https://jira.spring.io/browse/INT-3663
Previously the `ChannelSecurityInterceptorBeanPostProcessor` was populated with direct `BeanDefinition`s for `ChannelSecurityInterceptor`s.
It caused an `early access to BeanFactory`.
The issue has been introduced by the `ChannelSecurityInterceptorFactoryBean`
* Rework `SecurityIntegrationConfigurationInitializer` do not populate `BeanDefinition`s to the `ChannelSecurityInterceptorBeanPostProcessor`, but just `bean names`
* Redesign `ChannelSecurityInterceptorBeanPostProcessor` to the `AbstractAutoProxyCreator`
* Introduce `SecuredChannel` annotation to be used on the `@Bean` level for `MessageChannel` definition
* Move `access policy` mapping to the `SecuredChannel` annotation
Address PR comments
Document `@SecuredChannel` annotation
JIRA: https://jira.spring.io/browse/INT-3701
Allow Spring Boot to determine type created by GatewayProxyFactoryBean
Spring Boot's @ConditionalOnBean can be used to activate some
configuration when a bean of a particular type is present in the
application context. To avoid early initialization, the search for
beans is performed without instantiating them, i.e. it relies on the
information that's available from the bean's class and its bean
definition. This causes a problem with GatewayProxyFactoryBean as its
a FactoryBean<Object> so Boot's best guess is that the bean that's
produced by the factory will be an Object. For cases where the bean's
type signiture does not contain enougn information to determine its
type, Boot looks at an attribute, factoryBeanObjectType, on the
factory bean's definition. The value of this attribute can be a Class
or a String class name.
This commit updates MessagingGatewayRegistrar to set the
value of factoryBeanObjectType attribute to be the configured
service interface for the gateway.
JIRA: https://jira.spring.io/browse/INT-3697
Since Spring Integration 4.0 the `MessageHeaders` had been moved to the Spring Messaging module
and `MessageHeaders.CONTENT_TYPE` had been changed from `content-type` name to the `contentType`.
Previously the automatic mapping of `contentType` to the HTTP Request `Content-Type` has been introduced
for the `HttpRequestExecutingMessageHandler`.
This fix do the same for the HTTP Response in case of HTTP Inbound Endpoint.
This allows to transfer HTTP headers automatically from underlying HTTP Outbound Endpoint for HTTP Proxy scenario.
The response from that external HTTP service maybe changed during a downstream flow before sending HTTP Response from the HTTP Inbound Endpoint.
Before this we was forced to map `contentType` to `Content-Type` manually or just rely on the `HttpMessageConverter`s.
**Cherry-pick to 4.1.x**
JIRA: https://jira.spring.io/browse/INT-3686
Since `WebSocketInboundChannelAdapter` is positioned as an adapter for WebSocket client side as well,
the appropriate Server-side frames should be handler properly there, too, even if `StompSubProtocolHandler`
isn't designed for the client side usage.
* Add catch of the `CONNECTED` and `RECEIPT` STOMP message types to the `WebSocketInboundChannelAdapter`
* Emit `CONNECTED` as a `SessionConnectedEvent`
* Emit `RECEIPT` as a new introduced `ReceiptEvent`
**Cherry-pick to 4.1.x**
More coverage for the new events stuff
JIRA: https://jira.spring.io/browse/INT-3668
Note: the `defaultRequestChannel`, `defaultReplyChannel` and `errorChannel` remain as `MessageChannel` references,
since they are really some global shared and it looks logical to require those channels be populated by end-user directly
**Cherry-pick to 4.1.x**
This commit updates the version of Spring Web Services to
2.2.1.RELEASE. The fix for SWS-892 means that in the event of an
interceptor failing to handle a request, the request is no longer
sent. The interceptor in UriVariableTests has been updated to return
true, indicating that the request has been handled and should be
sent.
Conflicts:
build.gradle
spring-integration-ws/src/test/java/org/springframework/integration/ws/config/UriVariableTests.java
JIRA: https://jira.spring.io/browse/INT-3667
* fix `RedisLockRegistry.tryLock` memory leaks using 2 different thread local internal storages:
hard references for locked locks and weak references (optional) for others, weak references are used for lock obtaining optimization -
thread will get same `RedisLock` object for certain key before locking and after unlocking (if variable still exists)
* add `RedisLockRegistry.useWeakReferences` property for enable thread local weak references storage for unlocked locks, disabled by default
* fix `RedisLockRegistry$RedisLock.obtainLock` improper expire time update (expire time was updated on every attempt to get lock)
* update `RedisLockRegistry` tests
JIRA: https://jira.spring.io/browse/INT-3672
Previously the `IdempotentReceiverInterceptor` has been applied only for the `MessageHandler`s which were registered with `.handler` suffix.
Rework `IdempotentReceiverAutoProxyCreatorInitializer` and `IdempotentReceiverAutoProxyCreator` to get deal with **direct** `MessageHandler`s
which can be resulted from `@Bean` methods.
Use the `MessageHandler` real bean name instead of `endpoint pattern` in that case
**Cherry-pick to 4.1.x**
JIRA: https://jira.spring.io/browse/INT-3197
Polishing
Various glitches.
Fix Table of Contents
Polishing - Various Glitches
More Polishing
- Fixes for issues found by side-by-side comparison of htmlsingle output.
Fix Table Formats for PDF
More Polishing - PR Comments
More Polishing - Bad Titles
More Polishing
Work-Around for AsciiDoctor Problem
https://github.com/asciidoctor/asciidoctor/issues/1297
Use a blank line between includes rather than a comment
at the end of include files that end with a callout.
Remove Unresolved qName Entries
Fix Overview PDF Image Sizes
Highlight Schema Imports
More Image Fixes
INT-3197: Port DocBook Changes Since Conversion
Remove DocBook Files
JIRA: https://jira.spring.io/browse/INT-3680
Change parser to use the `setSubscriptionName` setter instead
of `setDurableSubscriptionName` which as the side effect of
unconditionally setting the subscription as durable.
JIRA: https://jira.spring.io/browse/INT-3664
Since all metrics are already direct for the integration components, we don't do any proxying from `IntegrationMBeanExporter`,
and even any other adjustments during BPP phases. Hence this stuff is already redundant for `IntegrationMBeanExporter`.
In addition this change fix the `early access to the BeanFactory from BPP` issue.
INT-3664: Address PR comments
Doc Polish
INT-3664: Polishing according the SF changes to the `PostProcessorRegistrationDelegate$BeanPostProcessorChecker`
JIRA: https://jira.spring.io/browse/INT-3656
The optimization (when no interceptors) inadvertently removed
the `preSend` DEBUG log.
Reinstate the DEBUG log.
Also change `ChannelInterceptorList` to a `static` class.
This avoids the access method invocation each time the channel's
`logger` is used. The only `AMC` field used was the `logger`; pass
it into the `CIL` via a constructor.
Old bytecode:
104: aload_0
105: getfield #14 // Field this$0:Lorg/springframework/integration/channel/AbstractMessageChannel;
108: invokestatic #60 // Method org/springframework/integration/channel/AbstractMessageChannel.access$1:(Lorg/springframework/integration/channel/AbstractMessageChannel;)Lorg/apache/commons/logging/Log;
111: invokeinterface #66, 1 // InterfaceMethod org/apache/commons/logging/Log.isDebugEnabled:()Z
116: ifeq 157
New bytecode:
98: aload_0
99: getfield #22 // Field logger:Lorg/apache/commons/logging/Log;
102: invokeinterface #60, 1 // InterfaceMethod org/apache/commons/logging/Log.isDebugEnabled:()Z
JIRA: https://jira.spring.io/browse/INT-3670
Exceptions during inbound message conversion are now routed to the error-channel (if present).
When there is no error-channel, the exception is thrown back to the container as before.
Add a note to the `jms.xml` about the `error-channel` usage changes
JIRA: https://jira.spring.io/browse/INT-3655
In addition, change `GatewayProxyFactoryBean` to the logic to ensure that the Reactor is really `optional`
INT-3655: Doc Polishing
JIRA: https://jira.spring.io/browse/INT-3669
Previously the `DelayHandler` incorrectly calculated a `delay` for values which are of the `Date` time.
It always used `new Date()` even for rescheduling for persisted messages.
* Fix `DelayHandler` to calculate `delays` against the `requestDate` of the delayed Message
* In addition fix the expression evaluation root object, when for rescheduling it was the message with `DelayedMessageWrapper` payload instead of original message.
**Cherry-pick to 3.0.x, 4.0.x, 4.1.x**
JIRA: https://jira.spring.io/browse/INT-3661
Previously there were a lot of noise from the `PostProcessorRegistrationDelegate$BeanPostProcessorChecker` for early access for beans.
That may produce some side-effects when some of `BeanFactoryPostProcessor`s won't adjust those beans.
The issue is based on two facts:
1. Loading beans from `BPP`, e.g. `IntegrationEvaluationContextAwareBeanPostProcessor` (or `ChannelSecurityInterceptorBeanPostProcessor` - https://jira.spring.io/browse/INT-3663)
2. Loading beans from `setBeanFactory()/setApplicationContext()` container methods
* Move all code from `setBeanFactory()` with access to the `BeanFactory` (e.g. `this.messageBuilderFactory = IntegrationUtils.getMessageBuilderFactory(this.beanFactory);`)
to some other lazy-load methods like `getMessageBuilderFactory()`
* Fix parser tests to remove `messageBuilderFactory` tests since there is no activity for target components to lazy-load them
* Polish some test according the new lazy-load logic
* Rework `IntegrationEvaluationContextAwareBeanPostProcessor` to the `SmartInitializingSingleton` and make it `Ordered`
* Populate `beanFactory` for the internal instance of `connectionFactory` in the `TcpSyslogReceivingChannelAdapter`
* Populate `beanFactory` for the internal `UnicastReceivingChannelAdapter` in the `UdpSyslogReceivingChannelAdapter`
* Add `log.info` that `UdpSyslogReceivingChannelAdapter` overrides `outputChannel` for the provided `UnicastReceivingChannelAdapter`
* Change the internal `MessageChannel` in the `UdpSyslogReceivingChannelAdapter` to the `FixedSubscriberChannel` for better performance
* Fix `AbstractExpressionEvaluator`
* Add JavaDocs for the `IntegrationEvaluationContextAware`
Fix `MongoDbMessageStoreClaimCheckIntegrationTests`
Addressing PR comments
JIRA: https://jira.spring.io/browse/INT-3651
- Add documentation for the new JMX environment
- Add the ability to customize the default metrics implementations
- Fix LifecycleMessageHandlerMetrics to get a custom `MessageHandlerMetrics`
- Add an escape to the bean pattern matcher to handle beans starting with `!`
INT-3651: More Docs/Polishing
* JavaDocs polishing
* Change `jmx.xml` to describe `public void stopActiveComponents(long howLong)` not that removed with `boolean force`
JIRA: https://jira.spring.io/browse/INT-3635
Add an expression as an alternative to `remote-timeout`.
INT-3635: Tcp GW Docs
Also removed the relationship between reply-timeout and
remote-timeout (introduced in 2.2 to provide backward compatibility
after the incorrect use of the reply-timeout attribute).
* Add log for Thread interruption state to the `EnableIntegrationTests`: https://build.spring.io/browse/INT-B41-JOB1-233
JIRA: https://jira.spring.io/browse/INT-3628
Certain tasks in Spring Integration are long running. Indicate
so for the benefit of platforms such as WebLogic that can log warnings
for long running tasks otherwise.
Also fix conflicting versions of commons-io.
JIRA: https://jira.spring.io/browse/INT-3577
It is no longer necessary to `flush()` the `BufferedOutputStream`.
Since INT-3575, the `TcpNetConnection` has flushed the stream.
The `TcpNioConnection` now does so too.
* Add `id` for the `<section>`s in the `whats-new.xml`
