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-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-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**
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-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-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-3657
With XML/DSL, the MMPP defaults to 1 (via the SPCAFB) but
@InboundChannelAdapter defaulted to -1 (infinity).
Change the annotation to be consistent with the XML/DSL.
Add missing schema docs for the `basePollerType`.
* Fix `AbstractMethodAnnotationPostProcessor` for `maxMessagesPerPollValue` override
* Change `EnableIntegrationTests#foo()` `@InboundChannelAdapter` to use `maxMessagesPerPoll = "2"`
and modify appropriate test-case to be sure that `maxMessagesPerPoll` isn't overriden as it has been done in the original commit.
JIRA: https://jira.spring.io/browse/INT-3641
Instead of maintaining a moving average on each event, store the events
for offline analysis.
Retain 5*window samples - this means that the earlies retained sample
contributes just 0.5% to the sum. E.g. with a window of 10, the earliest
sample is 0.9**50 (0.005).
Also, defer the conversion from nanoseconds to milliseconds to the
retrieval side.
Experimentation shows this increases perfomance by approximately 2x.
Sending 1B messages to nullChannel.
With Proxy: 1.2M/sec
Afer proxy removed: 2.4M/sec
With this change: 5.3M/sec
INT-3641: Polishing - PR Comments
JavaDocs polishing
JIRA: https://jira.spring.io/browse/INT-2230
Previously two global `<wire-tap>`s with the same `id` registered
two `GlobalChannelInterceptorWrapper` wrappers with generated names
for the same (last) `WireTap`. Hence the same `Message` has been sent to the the `wire-tap channel` twice (or more).
Fix the issue with overriding `GlobalChannelInterceptorParser#resolveId` with the `.globalChannelInterceptor` suffix.
Therefore the last `GlobalChannelInterceptorWrapper` wins overriding all others, if all our `<wire-tap>`s has the same `id`.
INT-2230: Add `id` to the global `channel-interceptor`
Polishing
JIRA: https://jira.spring.io/browse/INT-3653
After moving to nanosecond precision, the mean calculations were incorrect.
Add test cases to verify correctness.
JIRA: https://jira.spring.io/browse/INT-3601
* Move `setChannelResolver(DestinationResolver<MessageChannel> channelResolver)` to the `IntegrationObjectSupport`
* Introduce `IntegrationObjectSupport#getChannelResolver()`
* Change all `IntegrationObjectSupport` inheritors to use `getChannelResolver()` instead of direct `beanFactory` usage
* Fix `ServiceActivatorEndpointTests` do not fall
INT-3601: Addressing PR (JIRA) comments
Fixes failing tests
INT-3601: Address PR comments
JIRA: https://jira.spring.io/browse/INT-3653
Also switch to using `System.nanoTime()` for deltas.
INT-3653: Polishing; PR Comments
INT-3653: Polishing
* Fix `NullChannel` for the generic type
* Add `Assert.notNull` for metrics setters and for the result of `MetricsFactory`
* Fix compile and JavaDocs warnings
JIRA: https://jira.spring.io/browse/INT-3637
- Message Sources
- Message Handlers
Polishing; Final Review and PR Comments
- avoid second call to System.currentTimeMillis()
- fix elapsed time in handler metrics
- expose TrackableComponent when available
INT-3637: Add @IntergrationManagedResource
Prevents beans (channels, etc), which were previously picked
up via a proxy, from being exported by a standard context
MBeanExporter.
I looked at completely eliminating the MBeanExporterHelper,
which suppresses o.s.integration beans from being exported by
a standard MBeanExporter when there is an IMBE present, but I feel
this is too much of a breaking change. There are a number of
standard beans (such as WireTap) that are @ManagedResources and
these would disappear for users that don't have an IMBE.
That said, such beans previously disappear completely when there
*is* an IMBE so now they are now annotated with both so that
they are exported by at most one of the exporters.
Polishing; Use MBE.addExludedBean instead of DFA
INT-3639: JMX (AMQP/JMS) Channel Stats
JIRA: https://jira.spring.io/browse/INT-3639
Module channels inherit `ChannelSendMetrics`; add
`PollableChannelManagement` for polled channels.
INT-3638: JMX Initial Stats/Counts Settings
JIRA: https://jira.spring.io/browse/INT-3638
Add the ability to specify the initial settings for
'enableStats' and 'enableCounts' for MBeans that
support those statistics.
Polishing; PR Comments; Add Handler Metrics Test
Also found a problem using an inner MessageSource bean in an
inbound-channel-adapter - a BeanComponentDefinition was returned
instead of a BeanDefinition.
Add @DirtiesContext to JMX Tests
The new MonitorTests failed with InstanceAlreadyExistsException for the
errorChannel.
Add @DirtiesContext to all tests using the Spring test runner to avoid caching any
contexts after the test class completes.
INT-3637: JMX Support Negated Name Match Patterns
Note: with negated matches, order matters.
Polishing for `MonitorTests`
Fix `EnableIntegrationMBeanExport` JavaDocs
JIRA: https://jira.spring.io/browse/INT-3589, https://jira.spring.io/browse/INT-3624
* SF - 4.2. Fix Breaking changes for the `ApplicationEventPublisher`
* AMQP 1.5. Without issues
* Reactor - 2.0. Fix for the new `Stream` foundation
* jsonPath - 1.2.0. Fix for new `Predicate` abstraction. Add 'fail-fast error' to the `IntegrationRegistrar`
* Sshd - 0.13.0. Fix for new `VirtualFileSystemFactory` usage
* Spring Data - Fowler
* And others without issues
* Get rid of `reactor.util.StringUtils` usage
INT-3589: Address PR comments
Polishing
JIRA: https://jira.spring.io/browse/INT-3636
- Add `enableStats()` managed operation
- Delegate to a channel metrics object instead of using a proxy
INT-3636: Polishing; PR Comments
Change field name in `MBeanExporterHelper`.
INT-3636: Polishing
JIRA: https://jira.spring.io/browse/INT-3513
Removing the `rawHeader` access by the `DFA` improves performance.
Tests are added to verify that `MutableMessageBuilderFactory` does
what it purports to, and that the `MutableMessageHeaders` is now
applied, permitting updates to individual headers.
change `@since` to correct/probable release version
INT-3513: Polishing
JIRA: https://jira.spring.io/browse/INT-3626
Remove Direct Array Usages.
With the increased use of java configuration and DSL, it
is no longer safe to directly use array arguments.
(Except in simple wrapper objects).
Avoid (or mark //NOSONAR) catch Throwable.
Remove unused field.
JIRA: https://jira.spring.io/browse/INT-3632
- Use Map.entrySet()
- Double check locking only works when the field(s) are volatile
- Remove unnecessary instanceof tests
JIRA: https://jira.spring.io/browse/INT-3581
Move schemas to 4.2.
Add `selector-expression` to `<wire-tap/>`.
INT-3781: Fix What's New
Bump Namespace Version to 4.2
JIRA: https://jira.spring.io/browse/INT-3571
* Deprecate `LifecycleMessageSource` and change `SourcePollingChannelAdapter` to get deal with `Lifecycle` directly
* Add `Lifecycle` propagation for the `MessagingMethodInvokerHelper` and its users: `MethodInvokingMessageProcessor`,
`ServiceActivatingHandler`, `MethodInvokingMessageHandler`, `MessageTransformingHandler` etc.
* Fix the bug with `MessagingAnnotationPostProcessor` and `Proxy` for the target object, when we should process annotation on the root method,
but create `MethodInvokingMessageHandler` for the method on the `Proxy`. Apply this logic only when `Proxy` is `JdkDynamic`, because of `CGLIB`
does `proxy-target-class`. In case of `JdkDynamicProxy` throw `IllegalArgumentException` if the method isn't extracted to the service interface.
Add `Lifecycle` tests for all endpoint types
JIRA: https://jira.spring.io/browse/INT-3606
Close the store when an (S)FTP synchronizing MessageSource is stopped.
Will need another commit on 4.2.WIP to change to `Lifecycle`.
Add dirty Flag to Properties MetadataStore
Avoid unnecessary persists.
Remove unnecessary implementation of `AbstractInboundFileSynchronizingMessageSource#getComponentType()`
JIRA: https://jira.spring.io/browse/INT-3595
The https://jira.spring.io/browse/INT-3554 introduced `Expression` setter variants for those component who accepted only String before.
Since SF `BeanDefinition` is based on the JavaBean specification there is guaranty for stable work when we have overloaded setters.
The `ExpressionEvaluatingRequestHandlerAdvice` has been missed to fix that requirement
JIRA: https://jira.spring.io/browse/INT-3560
Previously, messages arriving at the delayer before the
the context was initialized would be emitted twice after
the context `refresh()` or a JMX invocation of `reschedulePersistedMessages()`.
When using a `SimpleMessageStore`, the "re" scheduled
message from the context refreshed event (or a JMX invocation)
would be re-handled unconditionally.
This was due to incorrect logic to handle the way the `SMS` stores messages.
Change the logic to correctly handle (ignore) duplicate scheduled
releases when using `SMS`.
JIRA: https://jira.spring.io/browse/INT-3565
Cast to `IntegrationObjectSupport` fails if the handler is
already proxied in `AbstractSimpleMessageHandlerFactoryBean`.
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-3551
* Rename `MetadataKeyStrategy` -> `MetadataEntryStrategy`
* Add `valueStrategy` to the `MetadataStoreSelector`
* Add `value-strategy` and `value-expression` to the `<idempotent-receiver>`
INT-3551: Add `@IR` support on service methods
Rework `MetadataKeyStrategy` just to the `MessageProcessor`
Fix Docs
Minor Doc Polishing.
JIRA: https://jira.spring.io/browse/INT-3550
* Make `RoutingSlipRouteStrategy#getNextPath` as `Object` return type. to allow to produce `MessageChannel` result, not only `beanName`
* Make `RoutingSlipHeaderValueMessageProcessor` ctor to accept `Object... routingSlipPath` instead of just String.
It is useful from JavaConfig, when we can use `RoutingSlipRouteStrategy` `@Bean` reference.
* Add JavaConfig test case to demonstrate how `RoutingSlipRouteStrategy` can get deal with inline `FixedSubscriberChannel`
and Lambdas together with Reactor Streams.
INT-3550: Polishing according PR comments
* Fix `AbstractMessageProducingHandler` to check if `nextPath` isn't empty String
* Add `RoutingSlipHeaderValueMessageProcessor` ctor check for the `routingSlipPath` entries types
* Add `RoutingSlipRouteStrategy` JavaDocs regarding the loop of strategy invocation
* Add `Process Manager` doc
Doc Polishing.
