https://build.spring.io/browse/INT-SI43X-230
Looks like Ruby engine takes some time to start and
`Jsr223InboundChannelAdapterTests` is slow as 3 seconds locally as well
* Change the script to JavaScript and now we have 200 millis
**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-4231
For `FileWritingMessageHandler` and (S)FTP outbound gateways, support
`FileExistsMode.REPLACE_IF_MODIFIED` to allow overwriting an existing file if
the source file modified time is different to the existing file.
Polishing
JIRA: https://jira.spring.io/browse/INT-4154
* Move `Transformers` for files to the `Files` factory
* Remove `@Deprecated` methods
* Fix `FilesTests` for new packages and removed methods like `.handleWithAdapter()`
Provide JavaDocs for File DSL and implement some new methods like `chmod()` and `renameFunction()`
Fix race condition in the `ScriptsTests` when even small time window delay may lead us to one more message in the queue
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
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
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-3970
NOTE: Don't see reason to back-port, because we have catched `ScriptingException` for the same reason at runtime.
Fix typo in the `AbstractScriptExecutor` method name.
Use that method from the `Assert`on the `engine`
Remove unnecessary assert for a null message.
Poller runs every 100ms; test asserts that no message is received in 10ms
Eliminate stderr: `include_class is deprecated. Use java_import.`
JIRA: https://jira.spring.io/browse/INT-3751
Result was null when `executeScript()` was invoked with non-null variables.
When variable are provided, the result variable is stored in the provided bindings.
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.
* Add `<script>` and `<expression>` to `<int:inbound-channel-adapter>`
* Refactoring for `DefaultInboundChannelAdapterParser`
* Introduce `ScriptExecutingMessageSource` to allow scripts' `MessageProcessor`
implementations work as a source for polling endpoint
JIRA: https://jira.springsource.org/browse/INT-2867
INT-2867: documentation
In addition the tests for Lifecycle attributes
Polishing
Make 'lang' attribute optional on a script element and
attempt to derive the language from the file extension.
Change return value on ScriptParser.deriveLanguageFromExtension to the language name
Polishing (PR Comments)
* add XSD element for nested router type
* add tests on the matter
* polishing for RouterParserTests
JIRA: https://jira.springsource.org/browse/INT-2893
INT-2893: Polishing
INT-2893: after rebasing to 3.0
XSD changes reverted from 2.2 and moved to 3.0
INT-2893 Polishing
Factor out common elements; fixing missing documentation for
`expression` within a `router` within a `chain`.
