* GH-3483: Fallback to RestTemplate.converters
Fixes https://github.com/spring-projects/spring-integration/issues/3483
When there is no reasonable way to determine a `Content-Type`
from the request message, do not set an `application/x-java-serialized-object`
as a fallback and let the `RestTemplate` to determine the target type and
conversion through its `HttpMessageConverter` set
* Remove `application/x-java-serialized-object` fallback from the
`AbstractHttpRequestExecutingMessageHandler`
* Adjust its log messages according `LogAccessor`
* Un`@Disable` `WebFluxDslTests` since fix was done in Spring Security
* Add `HttpRequestExecutingMessageHandlerTests.testNoContentTypeAndSmartConverter()`
* Mention change in `What's New`
* Fix language in whats-new.adoc
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
* Fix unused import in the `IntegrationRequestMappingHandlerMapping`
* Fix deprecations from Reactor
* Fix race condition in the `AbstractCorrelatingMessageHandlerTests`:
the discard message is sent much earlier than group is removed from the store.
Iterate group count call until it pass or 10 seconds timeout
* Remove list size assert in the `FtpServerOutboundTests`: looks like
it is not updated properly even if we have an expected content in the collection
* Increase timeout to assert remote files removal in the `FtpRemoteFileTemplateTests`
Fixes: https://github.com/spring-projects/spring-integration/issues/3366
When the same path is mapped for integration HTTP endpoint and MVC
method mapping, but different other mapping options (e.g. method)
and one of them fails to match, there is no way to try other
`RequestMapping` from the `DispatcherServlet` because
`RequestMappingHandlerMapping.handleNoMatch()` throws an exception
when no match instead of `null` according chain of responsibility logic
in the `DispatcherServlet`
* Rework `IntegrationRequestMappingHandlerMapping.handleNoMatch()` to catch
all the super exception and return `null` to the `DispatcherServlet` to let
it to try other `RequestMapping` from the configuration
* Change an order for `IntegrationRequestMappingHandlerMapping` to `-1`
to let it to be tried first before regular MVC `RequestMappingHandlerMapping`
* Add a test-case to ensure that mix-in Integration HTTP and MVC for the
same path works as expected without failing on first try
* Fix HTTP & WebFlux for a new CORS logic when `*` pattern
is used together with `allowCredentials`
* Fix RSocket module for deprecated API in SF
* The deprecated RMI API is left for the upcoming changes
* Fix MessagingGatewaySupport for reactive error
The `onErrorResume()` was in a wrong place for the
`doSendAndReceiveMessageReactive()`: we have to catch all the exceptions
from the top level `Mono`, not only a reply one as it was before.
Ensure in HTTP and WebFlux test that behavior is fixed
**Cherry-pick to `5.3.x` & `5.2.x`**
* * Remove unused imports
Co-authored-by: Artem Bilan <abilan@vmware.com>
* 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>
* GH-3283: HTTP Inbound handle SpEL errors
Fixes https://github.com/spring-projects/spring-integration/issues/3283
* Process all the request message preparation exceptions
in the provided error channel to let target application
to make a decision about an appropriate HTTP status instead of
default 500 Server Error
* * Rephrase `ResponseStatusException` doc in the http.adoc
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
* GH-3155: Add support for Java DSL extensions
Fixes https://github.com/spring-projects/spring-integration/issues/3155
Provide an `IntegrationFlowExtension` for possible custom EI-operators
in the target project use-cases.
* * Move `IntegrationFlowExtension` tests ot its own test class
* Make all the `IntegrationComponentSpec` ctors as `protected` for possible custom extensions
* Make some `BaseIntegrationFlowDefinition` methods and properties as `protected` to get them
access from the `IntegrationFlowExtension` implementations
* Document the feature
* * Fix language and typos in docs
* * Add `protected` to one more `GatewayEndpointSpec` ctor
* Add JavaDocs to `GatewayEndpointSpec` methods
* * Add `protected` to one more `JmsPollableMessageChannelSpec` ctor
* GH-3154: Support `UriBuilderFactory.EncodingMode`
Fixes https://github.com/spring-projects/spring-integration/issues/3154
Spring Framework now provides a `DefaultUriBuilderFactory.EncodingMode`
for encoding URIs in the `RestTemplate` before and after uri template
enrichment with uri variables.
Therefore `encodeUri` and manual uri variables substitution is not necessary
in Spring Integration HTTP components
* Deprecate `AbstractHttpRequestExecutingMessageHandler.encodeUri` in favor of
`DefaultUriBuilderFactory.EncodingMode` and respective configuration
on the `RestTemplate` in HTTP module and `WebClient` in WebFlux module
* * Really populate `uriFactory` into an internal `RestTemplate`
* Ensure in tests that `encoding-mode` is populated properly into an internal `RestTemplate`
* Clean up affected HTTP tests for AssertJ and JUnit 5
* * Clean up formatting
* * Apply fix for WebFlux module
* Add docs for new `encoding-mode` option
* * Remove unused import in the test
* Remove Boon dependency and its usage
* Remove overloaded methods from the `IntegrationFlowDefinition`
- we can simply rely now on the super class
* Remove (or rework) deprecated entities in the docs
* Fix tests for removed deprecated APIs
* Rework affected tests to JUnit 5
* Optimize logic in the `ExpressionEvaluatingParameterSourceFactory`
do not compute object if they are present in maps.
Plus extract some common code to the method
Fixes https://github.com/spring-projects/spring-integration/issues/3132
It turns out that Checkstyle EmptyBlock doesn't complain about
empty default ctor.
Plus a new check for `super();` call treats it as a violation
* Remove `super();` from all the no-arg ctors
* Code style clean up in the affected classes according
IDEA suggestions
* Fix new Sonar smells
* Shorten internal component names for graph
The long `IntegrationContextUtils.ERROR_LOGGER_BEAN_NAME` name
is used for `errorChannel` `LoggingHandler`'s endpoint.
It is too long for endpoint node in the graph meanwhile the
`errorChannel` is good everywhere
* Change an `IntegrationGraphServer` logic to shorten internal
component names before drawing a graph
* Introduce `IntegrationUtils.obtainComponentName()` for
shortening an internal name if any
* Use `IntegrationConfigUtils.BASE_PACKAGE` in the `IntegrationMBeanExporter`
instead of its own static property
* Remove `IntegrationConfigUtils.FACTORY_BEAN_OBJECT_TYPE` in favor
of introduced in SF `FactoryBean.OBJECT_TYPE_ATTRIBUTE`
* Rework affected test classes to JUnit 5
* Remove usage of deprecated options in the `@EnableIntegrationManagement`
* Document names shortening feature for graph
* * Improve `obtainComponentName()` function
* Add `IntegrationPattern` contract to implement on the target components
which represent particular EIP
* Add `IntegrationPatternType` with an internal `IntegrationPatternCategory`
to return from the component implementing `IntegrationPattern`
* Parse `IntegrationPatternType` in the `IntegrationNode` for potential
use on the UI for drawing a particular icon
* More pattern representations
* Clean up Checkstyle
* Fix JavaDocs
* Add `integrationPatternCategory` assertion into the `IntegrationGraphServerTests`
* Add more IntegrationPattern implementations
* Provide some delegation and overriding logic whenever we have
components wrapping
* Fix unused imports
* Add `inbound_gateway` pattern indicator
* Add conditional on `expectReply` to indicate a component as an
`IntegrationPatternType.outbound_channel_adapter` or
`IntegrationPatternType.outbound_gateway`
* Make some code clean up in affected classes
* Add a `gateway` type for `@MessagingGateway`
* Comment the reason for `outbound_gateway` type in the `AbstractReplyProducingMessageHandler`
* Bump `IntegrationGraphServer.GRAPH_VERSION`
* Add new attributes into graph sample in the `graph.adoc`
* Document an `IntegrationPattern`
* Apply changes for version 5.3
* Rebased into `5.3-WIP`
* Add a `whats-new.adoc` note about an `IntegrationPattern`
* Move `What's New` into `changes-5.1-5.2.adoc`
* Remove version from the `XSD` files:
1. Align with SF
2. The version for XSD doesn't matter for the current jar version,
since only the version is available in classpath is from the current
jar version
3. Modify `spring.schemas` to map all the possible versions for XSD
into the current one in a jar.
This way target applications can upgrade without changing the version
for XSD location and we don't need to require `versionless` variant
any more
4. The jar in classpath can handle only its own XSD, so independently
of version or no-version variants we still may fail because the current
jar may not support end-user code any more - need some fix over there
anyway.
* Remove `checkTestConfigs` Gradle task since we don't worry about XSD
version any more
* Modify `schemaZip` Gradle task to populate XSDs into a distribution
still with a version to avoid overriding on-line XSDs for version `1.0.x`.
We may consider not do that since SF doesn't and just bite a bullet
for always overriding those on-line XSDs to the actual one from the latest
release.
Fixes https://github.com/spring-projects/spring-integration/issues/3114
The contract of SpEL with its
`getValue(EvaluationContext context, @Nullable Object rootObject)` is
that we need to deal with provided `rootObject` even if it is `null`
and don't consult with `context.getRootObject()`
* Fix `ExpressionEvalMap` to have an internal `rootExplicitlySet`
to indicate that `root` explicitly provided by consumer, even if it is null.
According this flag call respective `Expression.getValue()`
* Add `@Nullable` to methods and their arguments into `ExpressionEvalMap`
& `FunctionExpression` to honor `Expression` contracts
* Populate an `HttpEntity` explicitly into `ExpressionEvalMap` from the
`HttpRequestHandlingEndpointSupport` and `WebFluxInboundEndpoint` for
full picture
* Fix JavaDocs indentations in the `ExpressionEvalMap`
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
Fixes https://github.com/spring-projects/spring-integration/issues/2987
To resolve XSD files properly from the classpath, their HTTPS reference
must be present in the `spring.schemas` to avoid the Internet interaction
for resolving an XSD file
**Cherry-pick to 5.1.x, 5.0.x & 4.3.x**
It turns out that `JdkSerializationRedisSerializer` by default is
based on the default Java class loader which may lead into
`ClassCastException` downstream after deserialization
* Make all the `JdkSerializationRedisSerializer` usage (default)
in Redis components based on the BeanFactory `ClassLoader`
* Fix tests to call `setBeanClassLoader()`
* Fix Mark Fisher's name in the `MultipartFileReader` :-)
**Cherry-pick to 5.1.x, 5.0.x & 4.3.x after restoring diamonds**
According Sonar report we need to re-implement `equals()` & `hashCode()`
methods in the `IntegrationWebExchangeBindException` since it
extends a `WebExchangeBindException` with those methods
* Add Validation to HTTP Inbound
* Pull a validation functionality from `WebFluxInboundEndpoint` to its
super class `BaseHttpInboundEndpoint` making a validation available for
the `HttpRequestHandlingEndpointSupport` as well
* Do the same for the `validator()` option in DSL for the
`HttpInboundEndpointSupportSpec`
* Add `validator` XML attribute for both HTTP and WebFlux inbound
endpoint XSDs
* Test parsers for a new `validator` option
* Document validation in the `http.adoc`
* Apply some polishing in the `http.adoc`, as well as in the
`HttpRequestHandlingEndpointSupport` JavaDocs
* Clarify in `webflux.adoc` that validation is applied for the
`Publisher` items before the payload is finally built for the message to
send.
* Add WebFlux into the table of endpoints in the `endpoint-summary.adoc`
* * Remove unused imports
* Fix `SimpleMessageListenerContainerSpec` for deprecated `txSize` option
* Add validation support into WebFlux Inbound
See https://stackoverflow.com/questions/56729517/spring-integration-webflux-validate-input-json-body
* Introduce a `WebFluxInboundEndpoint.validator` option to validate
a request payload after conversion HTTP request into a `Publisher`
* Expose a `WebFluxInboundEndpointSpec.validator()` option
* Introduce a `IntegrationWebExchangeBindException` to extend a
`WebExchangeBindException` for Spring Integration use-case.
such an exception is used in the `ResponseStatusExceptionHandler`
extensions, like one in Spring Boot for proper response rendering
* Test and document the solution
* * Remove unused imports from IntegrationWebExchangeBindException
It turns out that `contentType` header (as well as `Accept`) may be
converted into `MimeType` upstream before the message is sent into HTTP
Outbound Channel Adapter meanwhile the logic is only to support String
and MediaType
* Change the `DefaultHttpHeaderMapper` to support more generic `MimeType`
for the `Content-Type` and `Accept` HTTP headers which can simply be
converted to the expected `MediaType`
**Cherry-pick to 5.1.x & 5.0.x**
* Add `io.spring.nohttp` Gradle plugin into the build script and allow
it only on CI server, since it is going to parse every file
* Fix tests do not use `http` any more
* Fix `test.html` in the `mail` modules tests to exclude a Namespace for
OExchange XRD protocol
* Fix some files for new line in the end of file according Checkstyle
violations
* Encoding in AbstractHttpRequestExecutingMessageHandler.java is now done when flag is set
* Added test for URI Encoding
* Fixed checkstyle violations
**Cherry-pick to 5.1.x**
Since SF has deprecated `StandardAnnotationMetadata` ctors in favor
of factory method, we can't extend it any more to adapt annotation
attributed by the map generated from the XML attributes
* Introduce an `AnnotationMetadataAdapter` to request a
`getAnnotationAttributes()` implementation which is only a method used
in the target `registerBeanDefinitions()` implementations
* Use a new `AnnotationMetadataAdapter` whenever the `StandardAnnotationMetadata`
has been used before
* Use properly `cache()` for the `Mono` in the `ClientRSocketConnector`
* Don't require a `publisherElementTypeExpression` in the
`RSocketOutboundGateway`: the target element type is determined
automatically in the `DefaultRequestSpec.toResponseSpec()`
* SF has deprecated `MediaType.APPLICATION_JSON_UTF8`: fix all its usage
in favor of recommendations to use the `MediaType.APPLICATION_JSON` instead
* Also fix plain `application/json;charset=UTF-8` literals to use
`MediaType.APPLICATION_JSON` instead
* Add the support for a `Publisher`, `Resource` and `MultiValueMap`
into the `WebFluxRequestExecutingMessageHandler`
* Along side with the `WebFluxRequestExecutingMessageHandler.setPublisherElementType`
and `WebFluxRequestExecutingMessageHandler.setPublisherElementTypeExpression`,
add XSD support for the `publisher-element-type(-expression)`, which
is used for the element type when request body is a `Publisher`
* Polishing for `AbstractHttpRequestExecutingMessageHandler`
* Fix Sonar smells for affected classes
* Remove used imports
Doc polishing
* Fix complexity for DefaultHttpHeaderMapper
* Deprecate `DefaultHttpHeaderMapper` constants which are fully
Spring Web `HttpHeaders` constants
* Introduce lowercase constants for `getHttpHeader()` switch
* Reuse `HttpHeaders` API as much as possible
* Simplify logic in some methods to break them to smaller methods
* * Remove Java Streams from critical paths
* Rework `setHttpHeader()` for `switch`
* * Use `ObjectUtils.toObjectArray()` to simplify complexity
* * Fix complexity in `setAccept()`, `setAcceptCharset()`, `setAllow()`
& `setIfNoneMatch()` using newly extracted `valueToCollection()`
* GH-2872: Parse all the multi-part files
Fixes https://github.com/spring-projects/spring-integration/issues/2872
The same HTML form entry may have several files in the multi-part request.
Parse all of them in the `MultipartAwareFormHttpMessageConverter.java`
and re-map to the result `MultiValueMap`
**Cherry-pick to 5.1.x**
* * Add test for multi-part files
* Do not fix urls for the `http://apache.org/xml/features` when we
configure XML components
* Do not fix urls for localhost and fake links in tests
* Fix all the dead links in docs
