Fixes https://github.com/spring-projects/spring-integration/issues/2748
* Refactor more `MessageHandlingException`s to include `this` into an
exception message
* Revert using `MessagingException` in some places which really are not
about messaging.
This helps to wrap them into `MessageHandlingException` later in the
`MessageHandler` for the `BeanDefinition` reference
* Remove `volatile` from configuration properties in the affected
classes
* Remove already deprecated `JmsOutboundGateway.setPriority()`
* Add `resource` and `source` for `BeanDefinition` in the
`AbstractChannelAdapterParser` & `AbstractInboundGatewayParser`
* Document the feature
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`
* Fix wrong import order in tests
* Polishing for not closed application contexts
* Use diamonds
* Use proper assertion operators
* Remove redundant classes
* Improve performance in JPA tests
* Fix typos
* 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-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-4160
* Rename `Scripts.script()` to processor() for better context
* Add `Scripts.messageSource()` for the `ScriptMessageSourceSpec`
* Redo `DslScriptExecutingMessageProcessor` logic to deal with `GroovyScriptExecutingMessageProcessor` via reflection, since that class is a part of `SI-Groovy` module
* Upgrade to `JRuby-9.1.5.0`
* Get rid of reflection in the `DslScriptExecutingMessageProcessor`
* Introduce `ScriptExecutingProcessorFactory` and its `GroovyAwareScriptExecutingProcessorFactory` extension in the `groovy` module
* Register `GroovyAwareScriptExecutingProcessorFactory` as a bean via `GroovyIntegrationConfigurationInitializer`
* Use bean for `ScriptExecutingProcessorFactory.BEAN_NAME` in the `DslScriptExecutingMessageProcessor` to populate `delegate` and fallback to the regular `ScriptExecutingMessageProcessor` instantiation if there is no such a `ScriptExecutingProcessorFactory.BEAN_NAME` bean
AMQP Lambdas
Event Lambdas
Feed/File Lambdas
Gemfile/Groovy Lambdas
* Ensure that JavaDocs are checked via ` check.dependsOn javadoc`
* Add `@return` tag to the `MessageBuilder.readOnlyHeaders()`
checkstyle EmptyBlock
checkstyle fixRightCurly Script
checkstyle EmptyStatement
checkstyle RightCurly
checkstyle TailingWhite
checkstyle NeedBraces
Fix the line separator in the `fixRightCurly.gradle`
JIRA: https://jira.spring.io/browse/INT-3976
The class name in case of `StaticScriptSource` (for inline scripts) is required only for Groovy native engine.
Even if `GroovyScriptParser` provides an explicit `scriptClassName` option, we still can configure
`GroovyScriptExecutingMessageProcessor` with the `StaticScriptSource` from Java without the script class name.
Therefore the logic in the `GroovyScriptParser` isn't robust.
* Remove the `GroovyScriptParser` `scriptClassName` logic altogether
* Change the `GroovyScriptExecutingMessageProcessor` to rely on the Groovy native `scriptClassName` generation
in case of the `scriptSource` is provided without the class name option
* Fix the test for the actual generated script class name
JIRA: https://jira.spring.io/browse/INT-3958
* Introduce `compileStatic` and `compilerConfiguration` properties for the `GroovyScriptExecutingMessageProcessor`,
to allow to customize the Groovy Script compilation
* Introduce `compile-static` and `compiler-configuration` options on the `<int-groovy:script>` component
* Change `RefreshableResourceScriptSource.suggestedClassName()` to return the **full** file name together with the
extension. That may be useful during the filtering phase for Compiler customization
* Modify tests to demonstrate different Compiler customization tricks
* Since Spring Boot 1.4 is already based on the SF-4.3, make an appropriate upgrade, too
Doc Polishing
More Docs Polishing
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-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-3527
* `WebSocketInboundChannelAdapter` now handles `CONNECT` STOMP message and sends `CONNECT_ACK` message to the `WebSocketSession` immediately
* `ExpressionMessageProducerSupport` implementations now checks the result of `expression` and if it is a `Message<?>` it is sent to channel without creating a new one
which previously wrapped that `Message<?>` as the `payload`.
* Add `<script>` support to the `<outbound-channel-adapter>`
* Upgrade to the SF 4.1.1
* Add appropriate notes to the Docs
Previously, there was a `synchronized` block in the `GroovyScriptExecutingMessageProcessor`
to achieve thread-safety around script variables.
In addition, the parsing and executing logic was delegated to `GroovyScriptFactory`, who, in turn,
has its own `synchronized` around script parsing.
This causes a bottleneck in a messaging architecture.
* Introduce `GroovyScriptExecutor implements ScriptExecutor`
to encapsulate Groovy parsing and executing logic
* synchronize via `ReentrantLock` only when script resource `isModified()`
JIRA: https://jira.springsource.org/browse/INT-3166
INT-3166: Fixes and Polishing
INT-3166: add synchronized double check
INT-3166: Remove `GroovyScriptExecutor`
Polishing tests and logic around exceptions
Fix up some white space issues in Groovy*Tests
Previously, there was no logic to check, if a JSR223 script
was modified should be refreshed from the external resource.
* Fix `RefreshableResourceScriptSource` to take care of refreshing
on call `isModified()`
* Add `scriptSource.isModified()` before getting script text
* Introduce `ScriptSourceFactoryBean` to avoid I/O operations, when
there is need to refresh script resource - `refreshDelay < 0`
JIRA: https://jira.springsource.org/browse/INT-3164
INT-3164: change the refresh mutation logic
Remove factory bean - no longer needed.
This commit updates Spring Integration to depend upon Spring 4, making
use of the message types that have moved from Spring Integration into
Spring's new spring-messaging module.
The default message converter no longer supports conversion of a
message that is null, throwing an IllegalArgumentException if an
attempt is made to convert null. Furthermore, GenericMessagingTemplate
does not support sending null, again throwing an
IllegalArgumentException. Previously, MessagingTemplate had no-oped an
attempt to send null.
ConcurrentAggregatorTests and AggregatorTests both had a single test
that was specifically testing the behaviour of an aggregator that
returns null for its message. These tests have been removed.
CorrelatingMessageHandlerTests have been updated to specify some
additional behaviour for its mocks so that null messages are not
returned.
These are the only functional changes that have been made. All other
changes are simply for moving to the repackaged and/or renamed types.
In the move to being part of core Spring, a number of constants and
header accessor methods have moved from MessageHeaders to
MessageHeaderAccessor. This commit continues this pattern for
the enterprise integration headers that are specific to Spring
Integration. A new class, EiMessageHeaderAccessor, has been created.
This class provides constants and methods for working with SI-specific
headers. The main code and tests have been updated to use this new
class.
Previously, provided `MessageProcessor` to create a `MessageHandler`
for endpoint was wrapped to `MethodInvokingMessageProcessor`,
e.g. `GroovyScriptExecutingMessageProcessor`.
Check the type of provided object in the constructor
of `MethodInvoking*` strategies and use it directly if it is `MessageProcessor`
JIRA: https://jira.springsource.org/browse/INT-2433
Delegating consumer endpoints (<service-activator/> etc)
may not have both 'expression' and 'ref' attributes.
Previously, 'expression' was ignored when 'ref' was present.
- Enforce mutual exclusivity in AbstractDelegatingEndpointParser.
- Add tests for illegal combinations.
- Improve error message when 'method' used with <expression/>.
- Change parser to use reader.error() instead of Assert.
- Add element description to all parser errors.
* ban to use 'channel' and 'request-channel' attributes for 'outbound-channel-adapters' and 'outbound-gateways' when they are declared inside the `<chain>`
* fix usage of `<request-handler-advice-chain>` for components when they are declared inside the `<chain>`
* ban to use `<request-handler-advice-chain>` for 'outbound-channel-adapters' when they are declared inside the `<chain>` don't implement `AbstractReplyProducingMessageHandler`
* refactor `IntegrationNamespaceUtils` to use `BeanDefinition` instead of `BeanDefinitionBuilder` for 'advice-chain' parsing
* tests for new logic for 'channel' and 'request-channel' attributes within `<chain>`
* tests for new logic for `<request-handler-advice-chain>` within `<chain>`
* fix failed test on slow machine
* fix `SysLogTransformer` tests
For reference:
https://jira.springsource.org/browse/INT-2718https://jira.springsource.org/browse/INT-2721https://jira.springsource.org/browse/INT-2719
INT-2718 Polishing
Add general capability to advise just the handleRequestMessage
part of an AbstractReplyProducingMessageHandler.
This is to advise just the immediate operation, and not the
entire downstream flow.
Uses include:
* outbound gateway post processing
* adding retry behavior using spring-retry
* adding circuit breaker functionality
Initial commit for review.
Also need to advise simple message handlers (such as file
etc) to allow them to post-process file operations
with payload.delete(), payload.renameTo(...) etc.
INT-2250 Add Circuit Breaker Advice
INT-343 Add Retry Advice
Stateless and Stateful retry using spring-retry. Stateless
means the RetryTemplate performs the retries internally.
Stateful means the exception is thrown (e.g. to JMS container)
and the retry state is maintained by spring-retry.
INT-2215, INT-343, INT-2250 Refactoring
Factor out common abstract Advice class.
INT-2214 Catch Evaluation Expression Exceptions
If an onSuccess expression evaluation fails, add an
option so the user can decide whether such an exception is
caught, or propagated to the caller.
INT-2214 etc PR Review Polishing
INT-2214 etc Namespace Core, File, FTP
Add <request-handler-advice-chain/> to outbound endpoints.
INT-2214 etc. More Namespace Support
amqp, event, gemfire, groovy, http, ip, jdbc, jms, jmx, jpa, mail, rmi, sftp, twitter, ws, xmpp
INT-2214 etc Polishing
PR Review
INT-2214 etc Polishing
Don't catch Throwable.
Move Advice classes to handler.advice package.
* make 'Groovy Control Bus' similar to 'Expression Control Bus'
* add tests about `abstract` & `prototype` Beans
* fix about lost `groovy.lang.Script#println()` functionality in the `GroovyControlBusFactoryBean$ManagedBeansBinding`
* polishing `GroovyControlBusDelayerManagementTest` to show abilities & fixes with this issue
JIRA: https://jira.springsource.org/browse/INT-2631
INT-2631: polishing according to PR comments
Introduce VariableResolver, BeanFilter, FilteredBeanFactoryDecorator, GroovyVariableResolverBinding, refactoring ManagedBeansScriptVariableGenerator for usage GroovyVariableResolverBinding.
GroovyVariableResolverBindingTests.
additional tests for GroovyControlBus.
add 'spring-web' dependency for tests about 'request' custom scope.
Manual: change description about 'Groovy Control Bus' scripts limitation'.
INT-2567: Improve & refacror Groovy Control Bus
Introduce separate BindingOverwriteGroovyObjectCustomizerDecorator
Internal GroovyControlBusFactoryBean$ManagedBeansBinding with delegation to provided BeanFactory
Inline ScriptVariableGenerator implementation just for Message 'headers' variable
Tests for new GroovyScriptPayloadMessageProcessor logic about binding
Integration tests for managed beans in the custom scope
Reference Manual: polishing description about Control Bus' behavior
INT-2567 polishing added @link to javadocs
1. MethodInvokingHeaderValueMessageProcessor => MessageProcessingHeaderValueMessageProcessor because now he uses MessageProcessor
2. polishing HeaderEnricherParserSupport
3. GroovyHeaderEnricherTests: add check to HeaderValueMessageProcessor for Groovy scripts.
4. build.gradle: add dependency to 'spring-integration-test' for 'spring-integration-groovy'.
ServiceActivatorFactoryBean#createMessageProcessingHandler: force 'processMessage' method-name parameter into constructor ServiceActivatingHandler for MessageProcessor
Test for check 'handlerMethods' in ServiceActivatingHandler's MethodInvokingMessageProcessor
Integration test for <service-activator> with invalid Groovy inline script
