It looks like in the latest Hibernate there is some fix
in the persistent context where provided entity is updated by the values from
DB.
We are going to address those failing JPA tests post-release
The `JmsMessageDrivenEndpoint` delegates all the hard work to the
`ChannelPublishingJmsMessageListener`, but missed to propagate an `ObservationRegistry`
and other related options.
The `JmsInboundGateway` is worse: it delegated to the `JmsMessageDrivenEndpoint`
* Add `IntegrationObservation.HANDLER` observation to the `MessagingGatewaySupport.send()`
operation: used by the delegate in the `ChannelPublishingJmsMessageListener`
* Expose and propagate observation-related options from `JmsInboundGateway`
and `JmsMessageDrivenEndpoint`
* Expose `observationConvention()` option on the `MessagingGatewaySpec`
and `MessageProducerSpec`
* Remove unused imports
* Do not start a new `RECEIVER` observation if there is already `SERVER` one
* Fix `MessagingGatewaySupport` for `Observation.NOOP` check.
The parent process may still use `ObservationRegistry.NOOP` which sets
`Observation.NOOP` instance into the current context and thread local.
**Cherry-pick to `6.1.x` & `6.0.x`**
The `ScriptsTests.testKotlinScript()` fail with:
```
Caused by: javax.script.ScriptException: error: cannot access 'java.io.Serializable' which is a supertype of 'kotlin.Int'. Check your module classpath for missing or conflicting dependencies
2 + bindings["payload"] as Int
^
at org.jetbrains.kotlin.cli.common.repl.KotlinJsr223JvmScriptEngineBase.asJsr223EvalResult(KotlinJsr223JvmScriptEngineBase.kt:104)
at org.jetbrains.kotlin.cli.common.repl.KotlinJsr223JvmScriptEngineBase.compileAndEval(KotlinJsr223JvmScriptEngineBase.kt:63)
at org.jetbrains.kotlin.cli.common.repl.KotlinJsr223JvmScriptEngineBase.eval(KotlinJsr223JvmScriptEngineBase.kt:31)
at java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:231)
at org.springframework.integration.scripting.jsr223.AbstractScriptExecutor.executeScript(AbstractScriptExecutor.java:84)
```
* `--add-opens` for `java.lang` and `java.util`
in Groovy and Scripting modules to let `java.util.Date` scoped prototype bean
to work back with new CGLIB classpath limitations
* Fix `IntegrationGraphServerTests` to not use `net.minidev.json.JSONArray` API
since it is not available as transitive from `json-path` in the `testCompileClasspath`
* Remove `mockito-inline` dependency
* Fix deprecations from Spring Security
* Fix `SmbSessionFactoryWithCIFSContextTests` for compatibility with latest `JCIFS`
* Migrate all the SMB tests to Junit Jupiter
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
* Add `spring-web` test dep for `spring-integration-graphql` module
* Fix `MultipartAsRawByteArrayTests` according to the changes in the
`ByteArrayHttpMessageConverter` where it uses `ReadNBytes()` even for
`0` in `Content-Length` header
* Fix Kafka tests to use `RetryListener` interface with `default`
methods instead of already deprecated `RetryListenerSupport`
* Explicitly enable Jacoco XML report
Must be `xml.required = true`
* Starting with version 3 the Sonarqube Gradle plugin
does not do any automatic dependencies on other tasks:
https://docs.sonarqube.org/latest/analyzing-source-code/scanners/sonarscanner-for-gradle/
* It is also does not apply the task to sub-projects.
So, to make the root `sonarqube` task we need to have config like this:
```
rootProject.tasks['sonarqube'].dependsOn jacocoTestReport
```
Note: the `sonarqube` task is deprecated in favor of `sonar`,
but that is exactly what our current Bamboo Sonar plugin does.
So, when that is upgraded, we need to revise our config again
* We don't need `xml.outputLocation` since its default is what Sonar expects
Fixes https://github.com/spring-projects/spring-integration/issues/3772
* Add basic To/From Protocol Buffer's com.google.protobuf.Message transformers.
* Allow the proto_type header to specify the type.
* Add tests.
* add Protobuf docs
* Leverage the Spring ProtobufMessageConverter
* move protobuf-java-util to test dependecies as optional
* protobuf docs improvements
* improve the expected type handling
* expected type expression
* fix indentation
* fix indentation for generated test classes
* suppress style check for proto generated classes
* address the transformer doc format
* fix whats new merge conflict
* fix doc sample code
* Some code clean up; fixing typos
* Upgrade dependencies whenever it is reasonable
* Fix deprecations and some new API paths
* Move docs to a new version with respective branching for the `changes-5.5-6.0.adoc`
For better performance by default it is better to not pull
a `io.micrometer:context-propagation` a hard dependency.
* Remove `io.micrometer:context-propagation` dependency management
* It is pulled transitively by the `io.micrometer:micrometer-tracing-integration-test` in test scope
* Rework all the `ContextSnapshot` usage in the reactive code to respective recommended `handle()` API in `Flux` and `Mono`
To propagate an `Observation` from reactive stream (e.g. WebFlux)
we have to capture its context and set it into the current thread scope.
* Add a `io.micrometer:context-propagation` dependency to support reactive context propagation
* Populate a `parentObservation` in the `IntegrationObservation.PRODUCER.observation()`
since it is not available for tracing on `Observation.onStart()`.
Might be tentative until upcoming fix in Micrometer Observation
* Populate from reactive context in the `WebFluxInboundEndpoint` where we use just `send()` operation downstream
* Populate from reactive context in the `MessagingGatewaySupport` where we use `send()` operation downstream or `FluxMessageChannel.subscribeTo()`
* Use `contextCapture()` in the `FluxMessageChannel` to gather a `ThreadLocal` info into a Reactor context
and then set back to `ThreadLocal` in the `transformDeferredContextual()` which really happens on a different thread
* Verify a trace propagation from WebFlux to an integration flow via Brave instrumentation in the `WebFluxObservationPropagationTests`
* 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>
It looks like some of Spring project's bom added after `spring-framework-bom`
causes a mess with dependencies: it brings those SF deps which are in the
latest `mavenBom`
* Move `spring-framework-bom` to the end of the list to be sure that
its version comes properly
* Do the same for Spring Data - after Spring AMQP and Spring Kafka
* Copy docs to the `$buildDir/reference` instead of `docs`
to make `asciidoctor` tasks to calculate their UP-TO-DATE key properly
* Generate `kdoc` outside the `docs` dir to not interfere with `asciidoctor`
* Downgrade Tomcat to `10.0.23` since SF-6.0.0-RC3 is not compatible yet
* Exclude `jakarta.activation` and `com.sun.mail` transitive deps to avoid
classpath conflict with Jakarta EE 10
