https://build.spring.io/browse/INT-FATS5IC-430
Looks like there is a race condition when our polling rate around
data base is too fast and we have access to the DB files even during
application context close.
* Stop polling channel adapter in the tests explicitly after test methods
* Increase some tests performance decreasing timeouts to wait
* Upgrade to Reactor-3.1.5, AssertJ-3.9.1, Derby-10.14.1.0 and some
Gradle plugins
* Upgrade to `reactor-netty-0.7.5`
* Remove workaround from the `StompServerIntegrationTests`
* Upgrade to Spring Data Kay SR5
* Upgrade to Spring Security 5.0.3
* Increase timeouts and performance in the `StreamTransformerParserTests`
If there is `json`-aware `contentType` header in the message to process
and payload type is `String` or `byte[]` and it isn't equal to the
expected exclusive method argument type (even generic from the `Message<>`),
the conversion should happen only if SpelInvoker is no method.
The regular `InvocableHandlerMethod` takes care about payload conversion
via configured `MessageConverter` in the `PayloadArgumentResolver`
* Fix `MessagingMethodInvokerHelper` to call JSON conversion only when
`this.handlerMethod.spelOnly`
NOTE: We can't do generics conversion right now because it is going
to be a breaking change around
`org.springframework.integration.support.json.JsonObjectMapper` property
in the `MessagingMethodInvokerHelper`.
We can do that only in `5.1` and rely there only on the functionality
from the Jackson Object mapper
* Convert from JSON only in the `invokeExpression()`
* Optimize message recreation only if target param type is `Message`.
Otherwise override just `payload` property of the `ParametersWrapper`
JIRA: https://jira.spring.io/browse/INT-4413
When we override entity in the `IntegrationFlowContext.registry`,
we may get dangling beans in the application context,
when the structure of a new `IntegrationFlow` is different.
* Fix `IntegrationFlowContext` to disallow to override the flow
registration under the same name
* Add JavaDocs to the `IntegrationFlowRegistrationBuilder` methods
* Add `toString()` to the `IntegrationFlowRegistration` and
`StandardIntegrationFlow` to make the logging of these components
friendlier
JIRA: https://jira.spring.io/browse/INT-4411
The `RouterSpec.RouterMappingProvider` relies on the
`ContextRefreshedEvent` which happens only during application start up.
When we register `IntegrationFlow` at runtime, this event doesn't
happen and therefore sub-flow mappings don't populated.
* Fix `RouterSpec.RouterMappingProvider` to parse sub-flow mappings in
the `onInit()`
* Reorder components registration for the router in the
`IntegrationFlowDefinition` to let lately sub-flows to start earlier,
then lifecycles in the main flow
JIRA: https://jira.spring.io/browse/INT-4410
The `CollectionArgumentResolver` has been introduced especially for the
cases to work with `MessageGroupProcessor` (an aggregator)
when the payload is a `Collection<Message<?>>`.
This use-case doesn't apply for the general collection parameter use-case.
* Register `CollectionArgumentResolver` only when `listCapable` option.
For all other collection-based use-cases fallback to the standard
`PayloadArgumentResolver` with an appropriate configured `MessageConverter`
Note: this is for backward compatibility.
In the `5.1` we may reconsider to use `MessageConverter` in the
`CollectionArgumentResolver` as well, or just remove it altogether with
an appropriate logic in the `PayloadArgumentResolver`, since this
`CollectionArgumentResolver` solution isn't robust
JIRA: https://jira.spring.io/browse/INT-4402
Make `GlobalChannelInterceptorProcessor` as a `BeanPostProcessor`,
so it can apply global `ChannelInterceptor`s to any initialized channel
beans, even those created at runtime, like in case of dynamic flows with
Java DSL
**Cherry-pick to 4.3.x**
* Add `postProcessDynamicBeans` global property with `false` by default
* Rely on the `postProcessDynamicBeans` property in the
`GlobalChannelInterceptorProcessor.postProcessAfterInitialization()`
* Add `postProcessDynamicBeans=true` to the
`GlobalChannelInterceptorTests-context.xml` to be sure in the test-case
that option works
* Document the option and effect from the global channel interceptors
JIRA: https://jira.spring.io/browse/INT-4402
Previously, Micrometer instrumentation was only applied to components during
ApplicationContext initialization.
`IntegrationManagementConfigurer` is now a `BeanPostProcessor` as well as a
`SmartInitializingSingleton`, but only acts as a BPP after the context is
initialized. This enables Micrometer instrumentation to beans added later,
either via a new `BeanDefinition` or `bf.initializeBean`.
NOTE: destroying and re-creating a bean will use the same `Meters`.
JIRA: https://jira.spring.io/browse/INT-4396
When target distributed `Lock` implementation throws an exception, e.g.
in case of no connection to the service, the `LockRegistryLeaderInitiator`
exists the loop and can come back to the elections only after restart
* Catch all the exception on `this.lock.tryLock()` and resubmit
`LeaderSelector` for a new locking cycle if
`LockRegistryLeaderInitiator.isRunning()` and `InterruptedException`
* Remove diagnostics from the `JdbcLockRegistryLeaderInitiatorTests`
since this fix confirms that we just didn't have a reconnect logic before
when this test failed sporadically
**Cherry-pick to 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4394
Looks like Jackson has became much smarter and now it stores
the target type for the object, not returned interface.
We can't use Jackson annotations on the Framework classes and
we can't restrict the `messagingAwareMapper()` `ObjectMapper` just
to use fields for all the object passed through it.
As a compromise solution we shouldn't use
`Collections.unmodifiableList()` in the getter.
The copy of the internal collection is pretty enough to protect
our object from mutation.
**Cherry-pick to 4.3.x (excluding `build.gradle` change)**
Fixes https://github.com/spring-projects/spring-integration/issues/2301
* For non-ordered, without deduplication logic use-case the `ArrayList`
option for internal `SimpleMessageGroup` collection is added
* Make `SimpleMessageGroup` `protected` ctor as `public` for better
reuse in case of custom `MessageGroupFactory`
To avoid `Message` re-creation during `AbstractMessageSource.receive()`
logic, refactor `AbstractMessageSource` implementations
to return `AbstractIntegrationMessageBuilder`
* Add `AbstractIntegrationMessageBuilder<File> doReceive()` to the
`FileReadingMessageSource` to be called from the `AbstractInboundFileSynchronizingMessageSource`
to avoid message recreation in its `doReceive()`
* Some code style refactoring in the `AbstractMessageSource`
JIRA: https://jira.spring.io/browse/INT-3945
Adding test for async annotated ServiceActivator
fix whitespace
Address comments
Change copyright and author
* Some code style polishing
* Rename `Log4j2LevelAdjuster.level()` to more friendly `forLevel()`
factory method name.
* Add `@param level` to the `Log4j2LevelAdjuster.forLevel()` to fix
JavaDoc warning
* Add `WrappedJsonNode.getTarget()` API to let target users to get
access to the target `JsonNode` for their logic
* Some code style and JavaDocs improvements in the `JsonPropertyAccessor`
The `SpelPropertyAccessorRegistrar` ctor and
`add(PropertyAccessor... propertyAccessors)` method use wrong variable
to build a key for the provided `PropertyAccessor`.
Therefore during iteration the next `PropertyAccessor` overrides the
previous and we end up just only with one instance in the registry
* Extract `private static obtainAccessorKey()` method to build
decapitalized key for the `PropertyAccessor`
* Change the map store to the `LinkedHashMap` to keep order of the
provided `PropertyAccessor` s
* Modify `EnableIntegrationTests` to ensure that we support several
`PropertyAccessor` s and in the proper order
**Cherry-pick to 4.3.x**
* INT-4376: Upgage to Log4J 2
JIRA: https://jira.spring.io/browse/INT-4376
* Deprecate Log4J 1.x components in favor of newly added
a `Log4j2LevelAdjuster` JUnit `@Rule`
* Update all the logging configuration to Log4J 2
* Polishing after testing
JIRA: https://jira.spring.io/browse/INT-4371
Add an abstract message source that populates the message with a header containing
an abstraction that allows the application to acknowledge/reject/requeue the message.
(In amqp, for example, this would map to channel.basicAck(tag),
channel.basicReject(tag, false), and channel.basicReject(tag, true).
With some brokers (such as kafka), acknowledge and reject might be equivalent
since there is no automatic DLQ processing in kafka both would simply commit the offset.
Also include a strategy interface for a factory to provide the acknowledgment header.
Add MessageSourcePollableChannel
Fix typo
Polishing - PR Comments
- remove marker interface; just use presence of the header for auto-ack
- remove the MessageSourcePollableChannel - users can use a MethodInterceptor to enhance the message
- other PR comments
Save entire response to allow customization of the ack/nack actions.
Docs, Copyrights; add MessageSourcePollingTemplate
Polishing - PR Comments - support disabling auto-ack, when possible.
More Utilities
* Simple code style polishing
When the target Java Bean reader throws an exception it is wrapped to
the `InvocationTargetException` which `getMessage()` returns `null`.
* Extract the `cause` when `InvocationTargetException` and check the
`message` for null anyway.
* Also check for `null` before calling `toString()` in the
`SimpleJsonSerializer.toElement()`
JIRA: https://jira.spring.io/browse/INT-4367
When CGLIB proxy is used for messaging POJO invocation,
the `InvocableHandlerMethod` doesn't recognize method parameter
annotations and therefore the logic is wrong at runtime or just
rejected during method processing
* Use `AopUtils.selectInvocableMethod()` to select the proper method to
call according the provided proxy type
JIRA: https://jira.spring.io/browse/INT-4365
It is much useful to configure the `notPropagatedHeaders` as a set of
patterns to match.
In this case we can filter a group of headers with the common prefix or
suffix
* Allow to configure `AbstractMessageProducingHandler.setNotPropagatedHeaders`
as simple patterns; the `*` means filter all - not copy request headers
at all - similar to `transformer` behavior
* Add `ConsumerEndpointSpec.notPropagatedHeaders()` for Java DSL
* Add `not-propagated-headers` to the `<service-activator>`
Address PR comments; some other improvements
* Fix `ConsumerEndpointSpec#notPropagatedHeaders()` log message
* Improve `AbstractMessageProducingHandler.notPropagatedHeaders() logic
so any `*` in the set of patterns eliminates all others since it has
a highest priority
* Expose `requires-reply` for the `<transformer>` as a `true` by default
* Refactor a bit `AbstractStandardMessageHandlerFactoryBean` hierarchy to
avoid duplicated code
* Fix `message.adoc`
* Add `noHeadersPropagation` flag to the `AbstractMessageProducingHandler`
* Rework logic in the `updateNotPropagatedHeaders()` to store the array
of patterns instead of `Set` to avoid extra operation on each message
* Combine `noHeadersPropagation` with the `shouldCopyRequestHeaders()`
in the `createOutputMessage()` for logic to determine if we should start
the copy-headers procedure at all
* Revert `AbstractMessageProducingHandler.selectiveHeaderPropagation`
* Optimize `AmqpOutboundGatewayParserTests` performance from 3 secs to 0.5
Fix more NPEs in the `AbstractMessageProducingHandler`
The `ExpressionEvaluatingTransactionSynchronizationProcessor` wraps
an expression evaluation result to the `Message` unconditionally
* Don't wrap one message to another if SpEL result is a `Message` per se
* Don't wrap the received message to another if the `expression` isn't
configured.
**Cherry-pick to 4.3.x**
JIRA: https://jira.spring.io/browse/INT-3876
INT-3876 track groups ids in AbstractCorrelatingMessageHandler and docs
INT-3876 Fix merge conflict and add missing link in doc
INT-3876 Move groupId check in message group processor and rework on docs
INT-3876 Remove extra space from the doc
INT-3876 Fix checkstyle refer instance variable groupid correctly
INT-3876 Update aggregator doc with more details
* Polishing `aggregator.adoc`
* Rework `AbstractCorrelatingMessageHandlerTests.testDontReapMessageOfOtherHandler`
do not use redundant options
JIRA: https://jira.spring.io/browse/INT-550
* We need verify schema version and register `IntegrationRegistrar`
only once, not on parsing each element
* `@Ignore` time-sensitive `GroovyScriptExecutingMessageProcessorTests`
* Upgrade to Gradle-4.3.1 to overcome NPE with caches
JIRA: https://jira.spring.io/browse/INT-4363
* Register `HandlerMethodArgumentResolver`s in the
`IntegrationRegistrar` as `BeanDefinition`s to let them be configured by
the `BeanFactory` callback.
The direct instance doesn't call callbacks
* Use `JacksonPresent` in the `IntegrationRegistrar` instead of local
property
* Some code style polishing for the `IntegrationRegistrar`
* Add `JsonPathTests.testJsonPathOnPayloadAnnotation()` to ensure
that `PayloadExpressionArgumentResolver` is properly configured by the
`BeanFactory` and `#jsonPath()` SpEL-function is properly evaluated on
the `@Payload` for method `@ServiceActivator` method argument
JIRA: https://jira.spring.io/browse/INT-4363
The JIRA requests making the `MessageHandlerMethodFactory` a bean.
This is not possible without a major rework of the `MessagingMethodInvokerHelper`.
The problem is that the `InvokerHandlerMethod` s are created before the factory
is initialized. In fact, it only works at all since the IHMs have a hard reference
to the factory's argument resolvers so, when they are initialized in `initialize()`
each handler sees the resolvers.
This really needs to be improved but, since we are so close to GA, the compromise
was to add a `HandlerMethodArgumentResolversHolder` which holds the standard resolvers
which are then wired into the factory (along with the message converter).
Delaying the creation of the `InvokerHandlerMethod` is not trivial; today they are
built in the CTOR; moving it to `initialize()` would prevent the fast failure for
a badly configured bean; the proper solution might be to make the MMIHs beans themselves.
Polishing - PR Comments
Resolves: /spring-projects/spring-integration#2268
* To indicate the source the Redis message in the `RedisInboundChannelAdapter`
populate the `RedisHeaders.MESSAGE_SOURCE` header to the messages to produce
* Fix the `SimpleMessageConverter` to populate the provided `MessageHeaders`
to the message to produce
* Add `toMessage(T object, @Nullable Map<String, Object> headers)`
to the `InboundMessageMapper` to propagate additional header
to the message to create
* Rework all the out-of-the-box `InboundMessageMapper` implementations
to properly propagate additional headers via `toMessage()`
from the `SimpleMessageConverter`
* Provide optimizations in the `InboundMessageMapper` implementations
do not re-create messages
* Refactor `MutableMessage.toString()` to align with the `GenericMessage`
* Add more `@Nullable` to method arguments
* Increase latch wait timeout in the `EndpointParserTests`
* Address `redis.adoc` PR comment
JIRA: https://jira.spring.io/browse/INT-4362
INT-4312 added a JSON conversion when there is a single method with a non-String parameter.
Add more tests for parameters of type `Message`.
Catch conversion exceptions and use the message as-is if the conversion fails.
* Since we already have `PriorityChannelSpec` that isn't
`QueueChannelSpec` responsibility to worry about `priority` option.
More over it has been done wrongly and `MessageGroupQueue.setPriority()`
has been called unconditionally by the provided `ChannelMessageStore` type
* Fix `PriorityChannelSpec` logic as well:
- set `this.messageGroupQueue.setPriority(true);` to check the state of
the provided `PriorityCapableChannelMessageStore`
- fix assert condition in the `doGet()`
* And simple compiled SpEL test-case for the JDK Proxy
JIRA: https://jira.spring.io/browse/INT-4361
* To get a gain of the method chain code flow and avoid extra annotation
parsing, add `.role(String)` hook to the `EndpointSpec`
* Delegate the provided `role` property to the `AbstractEndpoint`
* Register `AbstractEndpoint` as itself `SmartLifecycle` in the
`SmartLifecycleRoleController`
* Add `destroy()` to the `AbstractEndpoint` and remove it from the
`SmartLifecycleRoleController`
* Provide some Java 8 code style refactoring
* Rework XML parsers and Annotation processors to populate `role`
property on the `AbstractEndpoint`
* Wrap `roleController` bean extraction to the `NoSuchBeanDefinitionException` catch
* Fix several `AbstractEndpoint` implementation to properly call
`super.onInit()` which has been missed before
