* 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
Some tests deliberately don't expect a reply, but they still block
on a gateway's `sendAndReceive()`
* Improve `Jsr223ScriptExecutingMessageProcessorTests`
to verify that script variables work
* Revise JS support for regular JVM
Turns out that we just need to have `org.graalvm.sdk:graal-sdk` and `org.graalvm.js:js`
dependencies for regular JVM to enable JavaScript support for Spring Integration Scripting module
* Add respective `providedImplementation` dependencies
* Remove `@EnabledIfSystemProperty` from unit tests
* Mention those dependencies in the doc
* Rework sentence in the doc for better English
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
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
* GH-3664: Re-enable JavaScript support via GraalVM
Fixes https://github.com/spring-projects/spring-integration/issues/3664
The JavaScript JSR223 engine has been removed from Java.
Migrate JavaScript support into GraalVM Polyglot API:
* Implement `PolyglotScriptExecutor` which can also support other GraalVM languages
* Change the `ScriptExecutorFactory` to use a `PolyglotScriptExecutor` when it encounters JavaScript
* Re-enable tests for JavaScript
* Add GraalVM Polyglot support into docs
* * Reinstate `@EnabledIfSystemProperty` for GraalVM JS system property
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
* Upgrade Spring dependencies to the latest SNAPSHOTs
* Fix tests to verify against stack traces: the message
of the `NestedRuntimeException` does not include the nested exception information.
Related to https://github.com/spring-projects/spring-framework/issues/25162
* Fix `JdbcMessageStore` and `DefaultLockRepository` to rely on the `DataIntegrityViolationException`
instead of only its `DuplicateKeyException` extension.
This is the current behavior of the SQL errors translation
* Disable `WebFluxDslTests.testValidation()` - doesn't subscribe to the reply somehow...
* Refine `SimplePool.PoolSemaphore.reducePermits()`
* Upgrade to Java 17, SF-6.0, Gradle 7.2
* Upgrade to Jakarta dependencies and respective namespaces
* Fix some tests for Java 17 compatibility
* Fix wrong Javadocs
* Add some missed Javadocs
* Fix more `jakarta` namespace
* Fix WS & XML modules to use Jakarta EE
* `--add-opens` in some modules for their reflection-based tests
* Disable Kafka tests which does not work on Windows; see Apache Kafka `3.0.1`
* Upgrade to JUnit `5.8.1`
* Migrate JMS tests to Artemis
* Remove RMI module as it was deprecated before
* Fix `pr-build-workflow.yml` for Java 17
* Fix JavaDocs warnings using `Xdoclint:syntax` per module, not in the top-level `api` task
* Move docs for version `6.0`
Since Nashorn JavaScript Engine is deprecated in Java 11 (https://openjdk.java.net/jeps/335)
it is better do nothing with JavaScript in the project any more
* Replace JS script tests to some other languages
* Mentioned deprecation in the Docs
* Rework `scripting.adoc` for code snippet switches
* Support Java 14
* Provide changes to avoid deprecated Java API
and have a compatibility back to Java 8
* Change affected test classes to JUnit 5 whenever it is possible
* Ignore/Disable some TCP/IP tests which don't pass on Java 14
* Fix (some) TCP tests on JRE 14
* Fix SSL Handshake test - client side handshake is successful with java 14
- change the badClient cert to a badServer cert to force an error on the client side
Co-authored-by: artembilan <raven666>
Co-authored-by: Gary Russell <grussell@pivotal.io>
* Add support for Kotlin JSR223 scripts
* Add required Kotlin dependencies into the `spring-integration-scripting`
module
* Introduce `KotlinScriptExecutor` to interact with the
`KotlinJsr223JvmLocalScriptEngineFactory` directly since there is no
`META-INF/services/javax.script.ScriptEngineFactory` file in the Kotlin
* Also set an `idea.use.native.fs.for.win` system property to `false` in
this class to disable check for native support on Windows.
(Might be removed in future Kotlin versions)
* Move `ScriptParser.getLanguageFromFileExtension()` logic into the
`ScriptExecutorFactory.deriveLanguageFromFileExtension()` since the same
one must be applied in the `DslScriptExecutingMessageProcessor`, too.
* Modify tests to reflect Kotlin support
* Fix some test scripts to their official extensions
* * Add JavaDocs
* Polishing according Sonar objections
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`
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`.
