* Mockito doesn't allow to `spy()` mocks any more or "overspy"
* Deprecate `KotlinScriptExecutor` if favor of fully supported JSR223
service loaded via `DefaultScriptExecutor`
* Use only one `kotlin-scripting-jsr223` dependency
Fixes https://github.com/spring-projects/spring-integration/issues/3986
The `ReactiveStreamsConsumer` in addition to plain `Subscriber` and `MessageHandler`
also supports a `ReactiveMessageHandler`, but `MockIntegrationContext` doesn't
handle a scenario when `ReactiveMessageHandler` is provided for consumer
* Rework the logic in the `MockIntegrationContext` to substitute a `ReactiveMessageHandler`
in the `ReactiveStreamsConsumer` which has a precedence in its logic over plain `Subscriber`.
* Wrap a plain `MessageHandler` mock into a `ReactiveMessageHandler` before substitution
in the `ReactiveStreamsConsumer`
* Reset `ReactiveStreamsConsumer.reactiveMessageHandler` with source `ReactiveMessageHandler`
or `null` respectively to an original `ReactiveStreamsConsumer` configuration
* Mention `ReactiveMessageHandler` use-case in the `testing.adoc`
**Cherry-pick to `5.5.x`**
Fixes https://github.com/spring-projects/spring-integration/issues/3686
* Add `src/idea` with respective editor config for IntelliJ IDEA.
Must be imported into an IDE
* Add `src/eclipse` with respective editor config for Eclipse/STS
* Reformat imports in source code according a new editor config
It is wrong to try to load an application context before test class in the `TestExecutionListener`
* Change `beforeTestClass()` phase for the `SpringIntegrationTestExecutionListener` to
the `prepareTestInstance()` when other `@BeforeAll` are already executed
**Cherry-pick to 5.5.x**
* GH-3844: Rework messaging annotation with @Bean
Fixes https://github.com/spring-projects/spring-integration/issues/3844
* Make `MessagingAnnotationPostProcessor` as a `BeanDefinitionRegistryPostProcessor`
to process bean definitions as early as possible and register respective messaging
components at that early phase
* Make bean definitions parsing logic optional for AOT and native mode since beans
have bean parsed during AOT building phase
* Introduce a `BeanDefinitionPropertiesMapper` for easier mapping
of the annotation attributes to the target `BeanDefinition`
* Remove `@Bean`-related logic from method parsing process
* Change the logic for `@Bean`-based endpoint bean names:
since we don't deal with methods on the bean definition phase, then method name
does not make sense.
It even may mislead if we `@Bean` name is based on a method by default, so we end up
with duplicated word in the target endpoint bean name.
Now we don't
* Fix `configuration.adoc` respectively for a new endpoint bean name logic
* In the end the new logic in the `AbstractMethodAnnotationPostProcessor`
is similar to XML parsers: we feed annotation attributes to the
`AbstractStandardMessageHandlerFactoryBean` impls
* * Fix language in docs and exception message
Fixes https://github.com/spring-projects/spring-integration/issues/3623
* `IntegrationFlow` refactoring
* Apply several code style improvements and good practices
* Code style: no empty lines for methods javadocs
* make deprecated implementation reuse actual one instead of the copy-paste approach
* add whats-new comments
* Fix whats-new page according to standards
* GH-3679: Better caching for SpringIntegrationTest
Fixes https://github.com/spring-projects/spring-integration/issues/3679
The `@SpringIntegrationTest` makes a test cache key based on its attributes values
when the same application context can be used in different test classes
with different endpoints to have stopped originally.
* Rework an `IntegrationEndpointsInitializer` to the `SpringIntegrationTestExecutionListener`
which consult a `MockIntegrationContext` for endpoints to be started or not before
the test execution and definitely stopped after the test execution to have a flexibility
with the cached context
* Improve a `MockIntegrationContext` to gather `AbstractEndpoint` beans and have them
marked for stopping in the beginning of the application context.
The `SpringIntegrationTestExecutionListener` takes care about startup in its `beforeTestClass()`
* Verify different state for the `SpringIntegrationTest` with the `CachedSpringIntegrationTestAnnotationTests`
* * Improve `SpringIntegrationTestExecutionListener` performance
when no `@SpringIntegrationTest.noAutoStartup()` is configured
* Fix `CachedSpringIntegrationTestAnnotationTests` check `isRunning()`
for the endpoint under the testing instead of `isAutoStartup()`
which is changed in one test class, but not other, and the order
of their execution would matter
* Migrate `MockMessageSourceTests` to JUnit 5 as a roadmap of the whole project
* Fixes https://github.com/spring-projects/spring-integration/issues/3787
* Clean up code style in Gradle configs
* Fix JavaDoc errors
* Make JUnit 4 as `optional` dependency for `spring-integration-test-support`
* Remove redundant `javax.activation-api` from some modules
* GH-3182: Properly reset bean in the MockIntCtx
Fixes https://github.com/spring-projects/spring-integration/issues/3182
The `MockIntegrationContext.resetBeans()` doesn't really restore a state
of endpoint beans: the handle/source is applied only after start for that endpoint
* Stop endpoints in the `MockIntegrationContext.resetBeans()` is they are running currently
* Start them back only if their `autoStartup == true`
* Clear only those beans which names are provided for the `resetBeans()`
**Cherry-pick to 5.2.x**
* * Ensure that only provided beans are reset
* Defer Messaging annotations process
The `AbstractMethodAnnotationPostProcessor` and its implementations
have a `beanFactory.getBean()` call for the `@Bean` methods with
Messaging annotations.
This is done, actually, from the
`MessagingAnnotationPostProcessor.postProcessAfterInitialization()`
which might be still too early in some scenarios, like Spring Cloud Feign
with its child application contexts being initialized from the
`FeignClientFactoryBean`, causing a `BeanCurrentlyInCreationException`
See https://stackoverflow.com/questions/54887963/beancurrentlyincreationexception-when-using-spring-integration-with-spring-cloud
* Implement a `SmartInitializingSingleton` for the `MessagingAnnotationPostProcessor`
and gather `Runnable` wrappers for newly introduced `postProcessMethodAndRegisterEndpointIfAny()`
to be called later in the `afterSingletonsInstantiated()` when context is
still in the initialization phase.
All runtime-registered beans are going to be processed normally from the
regular `postProcessAfterInitialization()`
**Cherry-pick to 5.1.x**
* * Fix unused imports in the `MessagingAnnotationsWithBeanAnnotationTests`
* * Fix `IntegrationEndpointsInitializer` in the testing framework to handle
all the possible `AbstractEndpoint` beans registration.
See its JavaDocs for more info
* Fix `AbstractCorrelatingMessageHandlerParser` and
`AbstractConsumerEndpointParser` to use bean names for `outputChannel`
and `discardChannel` instead of bean references.
Since `MessagingAnnotationPostProcessor` now registers endpoints and
beans for channels much later, than parsers, we can't rely on bean
references any more there.
* Fixes for failing tests which expected `outputChannel/discardChannel`
bean references, when it is already just their names for late binding.
* Apply some code style polishing for the affected classes.
* Add `@Nullable` for `MessageSelector` parameter in the `QueueChannel.purge()`
Mostly thanks to IDEA's plugin: https://plugins.jetbrains.com/plugin/10345-assertions2assertj
There is still a lot of work to do when complex and composite matchers are used.
* Add `awaitility` dependency and deprecate `EventuallyMatcher` in favor
of `awaitility`
* Remove Hamcrest from dependencies and disable JUnit & Hamcrest
static imports to encourage to use only AssertJ
* Migrate JUnit assumptions in rules to AssertJ's assumptions
* Deprecate some custom matchers in favor of existing in Hamcrest
after upgrading the last to version `2.1`
* Replace `ExpectedException` rules with `assertThatThrownBy()`
* Mention `MessagePredicate` in the `testing.adoc`
JIRA: https://jira.spring.io/browse/INT-4535
For the proper Spring Test Context caching support, the `ContextCustomizer`
must implement `hashCode()` and `equals()` methods
* Add `hashCode()` and `equals()` into the `MockIntegrationContextCustomizer`
* Ensure that caching works as excepted with the
`CachedSpringIntegrationTestAnnotationTests` its two sub-classes
**Cherry-pick to 5.0.x**
JIRA: https://jira.spring.io/browse/INT-4537Fixesspring-projects/spring-integration#2582
* Rename `ReactiveStreamsConsumer.messageHandler` property to the
`handler` for consistency with other `IntegrationConsumer` s
* Do not wrap `Subscriber` into the `MessageHandler` if that one is
already a `MessageHandler`
* Fix `MockIntegrationContext` for the logic around `ReactiveStreamsConsumer`
where it is not enough just replace a `handler`, but we also need to do
that with the `subscriber`.
Luckily the `MockMessageHandler` is also a Reactive `Subscriber`
* Clean up `MockIntegrationContext.beans` in the end of `resetBeans()`
* Improve `testing.adoc`
**Cherry-pick to 5.0.x**
JIRA: https://jira.spring.io/browse/INT-4432
The `MockIntegrationContext.substituteMessageHandlerFor()` method
cannot get the correct output channel of target message handler
since the `outputChannel` property is not initialized.
* Use `getOutputChannel()` method instead of directly accessing
the `outputChannel` property. The `getOutputChannel()` method
guarantees the correct value is retrieved.
* Polishing Copyrights and author name
* Simplify `MockMessageHandlerTests.testHandlerSubstitutionWithOutputChannel()`
and its configuration
**Cherry-pick to 5.0.x**
JIRA: https://jira.spring.io/browse/INT-4390
Phase I: flow context/registration cycle
- extract interfaces
- rename implementations to `Standard...`
Phase II - dsl<->dsl.channel tangles
Move the channel specs to dsl.
Fix missing refactorings
(Not related to DSL) - rename core `event` package to `events`
- avoid collision with event module package
- fix tangle caused by `MessageGroupExpiredEvent`.
Phase III - dsl<->config.dsl
- move classes from config.dsl to dsl
(Not related to DSL) - fix many tangles caused by graph being a sub-package of support.management
- make `graph` a top-level package
(Not related to DSL) - move `IntegrationManagementConfigurer` from
`management` to `config` - tangle between core and management
* Polishing Copyrights, diamonds, some JavaDocs and What's New
* 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
Fix PayloadMatcherTests for generics
Address PR comments and other improvements
* Revert `rawtypes` mode for the `PayloadMatcher`
* Make `HeaderMatcher` as `rawtypes` as well
* Make `MockMessageHandler` expect `rawtypes` for `Matcher`s.
This way we can just support `Matcher`s like `notNullValue(Message.class)`
* Rename `expect()` to `assertNext()`
* Rename `andReply()` to `thenReply()`
* Track replies are supplied in the `MockMessageHandler`
* Distinguish simple `MH` from the `MP` types in the
`MockIntegrationContext#instead()` do not let to replace simple `MH`
with fully configured `MockMessageHandler` or any other `MP` implementation.
Fail replace if types mismatch; wrap `MockMessageHandler` to simple `MH`
if it doesn't have replies when we are going to replace simple `MH`
* Wrap `MockMessageHandler` to the `Mockito.spy()` in the
`MockIntegration#mockMessageHandler()` to allow to `verify()` interaction
in the test-case
Remove wrapping `MockMH` to raw `MH` when no reply supported.
If `MockMH` isn't supplied with replies ti's safe to use it as is - no harm to target endpoint
which supposed to be last one in the flow
Some polishing and JavaDocs
More JavaDocs
Add docs for the `MockMessageHandler` and fix some JavaDocs
Make the `MockMessageHandler` with an API like:
```
MockIntegration.mockMessageHandler()
.handleNext(Consumer<Message<?>>)
.handleNext(Consumer<Message<?>>)
.handleNextAndReply(Function<Message<?>, Object>)
.handleNext(Consumer<Message<?>>)
.handleNextAndReply(Function<Message<?>, Object>)
.handleNextAndReply(Function<Message<?>, Object>);
```
Doc Polishing
JIRA: https://jira.spring.io/browse/INT-4251
MockIntegration PoC
Demonstrate how `MockIntegration.mockMessageSource()` can be used.
Even from the XML Config!
The same semantics can be applied for any other our mocking features we will add to the `MockIntegration`
Add `testMockMessageSourceDynamicFlow()`
Improve `MockIntegration.Context.instead()` for target bean type assertion
Some refactoring, improvements and JavaDocs
* Move `MockIntegration.Context` to its own `MockIntegrationContext` class
* Rename `@MockIntegrationTest` to `@SpringIntegrationTest` since we talk there not only about mocks, but any other possible testing feature for integration
* Add `@SpringIntegrationTest#stopEndpoints()` attribute for endpoints bean names patterns
* Add `IntegrationEndpointsInitializer` to customize `AbstractEndpoint`s according options from the `@SpringIntegrationTest`
Right now it is only about making them `autoStartup = false`
* Rename `SI-test` to `SI-test-support`
* Rename `SI-mock` to `SI-test`
* Rename `@SpringIntegrationTest#stopEndpoints()` to `noAutoStartup()`
* Fix JavaDocs according PR comments
* Increase timeouts in some sporadically failed tests
* Draft for the `testing.adoc`
Fixesspring-projects/spring-integration-java-dsl#23
Fix `testing.adoc` a bit
* Document Testing Support
* Fix a couple typos in the `xml.adoc`
* Add `package-info.java` files to `/test/` sub-packages
Improve docs according PR comments
Fix typos in `TestUtils` JavaDocs
Add `What's New` note about Java DSL and Testing support
Doc Polishing
JIRA: https://jira.spring.io/browse/INT-4214
* Rework `MessagingMethodInvokerHelper` to delegate to the `InvocableHandlerMethod` with its `HandlerMethodArgumentResolver` infrastructure instead of SpEL
* Introduce several `HandlerMethodArgumentResolver` to address some SI use-cases like `@Payloads`, `@Payload(expression = "")` and `Collection` as argument
* Initialize `DefaultMessageHandlerMethodFactory` in the `MessagingMethodInvokerHelper.start()`.
With that I observed several `Lifecycle` problem when we don't have proper delegate from the top.
* Fix `AbstractCorrelatingMessageHandler` and similar to delegate `Lifecycle` properly
* Fix `ReactiveConsumer` to delegate `Lifecycle` to the `MessageHandler`
* Fix `MutableMessage` do not `generateId()` and set `timestamp` headers if we already have them in the provided headers
* With all that `Lifecycle` many tests must be fixed to call `start()`
Add SpEL fallback variant to the MessagingMethodInvokerHelper
Add `MessagingMethodInvokerHelper.setUseSpelInvoker(boolean)`
Add `MethodInvokingMessageProcessorTests.testPerformanceSpelVersusInvocable()`
Add Compiled SpEL comparison
* Add `MapArgumentResolver` to cover `Properties` case
* add `MessagingMethodInvokerHelper.HandlerMethod.spelOnly` state, when we definitely can perform ony SpEL for provided arguments, e.g. `@Header` with expression
* Catch `IllegalStateException` with the `"argument type mismatch"` message to fallback to SpEL invocation
* Add `Iterator` support for the `CollectionArgumentResolver`
* Add `integrationConversionService` bean registration into the `TestUtils.createTestApplicationContext()`
* Tweak `.travis.yml` to try to download latest JDK, the current `1.8.0_31` is pretty old already and has some bugs
* Adjust some failing tests to use `TestUtils.createTestApplicationContext()` to rely on newly added `integrationConversionService` bean
Fix failed tests: `ctx.refresh()`
Polishing current year in Copyright
* JavaDocs for `CollectionArgumentResolver` and `MapArgumentResolver`
* Propagate `ConversionService` from the `MessagingMethodInvokerHelper` to the `MapArgumentResolver.java`
Fix `MessagingMethodInvokerHelper` to propagate `BeanFactory` into `MapArgumentResolver` as well
The `MapArgumentResolver` now `extends AbstractExpressionEvaluator`, too
Fix JavaDoc typo
JIRA: https://jira.spring.io/browse/INT-4206
* Fix unnecessary dependency resolution in BOM module
* Fix `MessagingMethodInvokerHelper` to handle `$MockitoMock$` generated classed which isn't CGLib `Proxies` any more
* Provide fixes for test classes according upgrade to Mockito `2.5`
* Fix Ceckstyle do not allow static imports for deprecated Mockito classes
https://sonar.spring.io/component_issues?id=org.springframework.integration%3Aspring-integration%3Amaster#resolved=false|types=BUG
In `IntegrationFlowRegistration` double check locking is ok for `inputChannel`
because we're assigning an existing object, but `MessagingTemplate` constructs
a new object for which double check locking doesn't work.
In any case, for both these items, the chance of concurrent access is extremely low
and is idempotent anyway, so remove double check locking.
Several inner classes can be static.
Other minor fixes.
* Add `ConsumerSubscriber` to adapt `Consumer<?>` to the `Subscriber<?>`
* Add `SubscribableChannelPublisherAdapter` to adapt `SubscribableChannel` to `Publisher<?>` via `Flux.create()` on subscription
* Add `PollableChannelPublisherAdapter` to adapt `PollableChannel` to `Publisher<?>` via `Mono.delayMillis()` and `flatMap()` for `channel.receive()`
Use `concatMap()` for `PollableChannel`
Iterate `PollableChannel` until there is a data
Fix Lambda signature error via explicit class declaration:
```
java.lang.ClassFormatError: Duplicate field name&signature in class file org/springframework/integration/endpoint/ReactiveConsumer$PollableChannelPublisherAdapter$1
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.springframework.integration.endpoint.ReactiveConsumer$PollableChannelPublisherAdapter.lambda$new$2(ReactiveConsumer.java:163)
```
Looks like Java bug:
Move `Iterator<Message<?>>` instance to the `subscribe()` to avoid race conditions when we have several subscribers.
In other words make `Iterator<Message<?>>` subscriber-specific, but at the same time avoid re-instantiation for each `Flux.concatMap()` call caused by the previous `repeat()`
Upgrade to Reactor 3.0.3 and others
* Make fixes according Reactor 3.0.3 changes
* Remove redundant `TestSubscriber` in favor of `StepVerifier` and `mock(Subscriber)`
* Rework `PublisherIntegrationFlow` Reactive Streams implementation to the out-of-the-box `ReactiveConsumer` and `ReactiveChannel`
Polishing - PR Comments and Closeable Warnings
Eclipse emits bogus warnings with exceptions in lambdas.
Even though the lambda might run on another thread, elipse thinks it could
cause the context to not be closed.
SPR-14854: MessageChannel is now a @FunctionalInterface
* Additional Lambda polishing and some code style fixes
* Upgrade to Checkstyle `7.1`
* Relax `RequireThis` rule a bit. Right now it does the effort only in case of overlapping. See https://github.com/checkstyle/checkstyle/issues/2362 for more info
* Enable some annotation rules and provide fixes for violations
* Enable `tabs indents` rule. This was the biggest fix in this PR
* Resolve `TODO` in the `MessagingMethodInvokerHelper` and fix tests to meet `IllegalStateException` now
Remain Checkstyle version `6.16.1` and reinstate `RequireThis` rule
The latest Checkstyle has a bug with local scope variables if they have the same names as property.
Revert some literals splitting
Fix some line length exceeding and code style
JIRA: https://jira.spring.io/browse/INT-3996
One of the query provider implementations was missing. To avoid a maintenance
nightmare, simply reference the interface's javadoc which lists all known
implementations.
* Simple `JdbcChannelMessageStore` JavaDocs polishing
* Add `LogAdjustingTestSupport` to the `StompIntegrationTests` to trace failures in the future.
* Also change the test `Start/Stop` messages to the `WARN` level in the `LogAdjustingTestSupport`, because `DEBUG` doesn't work everywhere.
Maybe some logging systems mix misconfiguration, like we have in the WebSocket modules with the Embedded Tomcat
