-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Spring DSL defaultOutputToParentFlow does not behave as described #3946
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
5.1.x is no longer supported: https://spring.io/projects/spring-integration#support See /**
* By default, if a resolved channel key does not exist in the channel map, the key
* itself is used as the channel name, which we will attempt to resolve to a channel.
* Invoke this method to disable this feature. This could be useful to prevent
* malicious actors from generating a message that could cause the message to be
* routed to an unexpected channel, such as one upstream of the router, which would
* cause a stack overflow.
* @return the router spec.
* @since 5.2
*/
public RouterSpec<K, R> noChannelKeyFallback() {
this.handler.setChannelKeyFallback(false);
return _this();
} |
All right, thank you for the information. Sorry to bother with an unsupported version. |
The property for version you use is this:
More JavaDocs are here:
And respective docs: https://docs.spring.io/spring-integration/docs/current/reference/html/message-routing.html#router-common-parameters-all. Since this Reopening... |
Good point @artembilan I had forgotten about that property; while polishing the javadocs, we should note that |
Fixes spring-projects#3946 The `AbstractMappingMessageRouter` has both `resolutionRequired` and `channelKeyFallback` as `true` by default. End-users expects them to back off when they set a `defaultOutputChannel`. They really want something similar to Java `switch` statement * Change the logic in the `AbstractMappingMessageRouter` to reset `channelKeyFallback` to `false` when `defaultOutputChannel` to avoid attempts to resolve channel from name, but rather fallback to `defaultOutputChannel` as it states from th mentioned Java `switch` statement experience * Deprecate `RouterSpec.noChannelKeyFallback()` in favor of newly introduced `channelKeyFallback(boolean)` * Call `channelKeyFallback(false)` from an overloaded `defaultOutputToParentFlow()` to reflect the mentioned expected behavior in Java DSL as well. * Respectively, deprecate `KotlinRouterSpec.noChannelKeyFallback()` wrapper in favor of newly introduced `channelKeyFallback(channelKeyFallback: Boolean)` * Remove redundant already `noChannelKeyFallback()` option in the `NoFallbackAllowedTests` * Document the change and new behavior
Fixes spring-projects#3946 The `AbstractMappingMessageRouter` has both `resolutionRequired` and `channelKeyFallback` as `true` by default. End-users expects them to back off when they set a `defaultOutputChannel`. They really want something similar to Java `switch` statement * Change the logic in the `AbstractMappingMessageRouter` to reset `channelKeyFallback` to `false` when `defaultOutputChannel` to avoid attempts to resolve channel from name, but rather fallback to `defaultOutputChannel` as it states from th mentioned Java `switch` statement experience * Deprecate `RouterSpec.noChannelKeyFallback()` in favor of newly introduced `channelKeyFallback(boolean)` * Call `channelKeyFallback(false)` from an overloaded `defaultOutputToParentFlow()` to reflect the mentioned expected behavior in Java DSL as well. * Respectively, deprecate `KotlinRouterSpec.noChannelKeyFallback()` wrapper in favor of newly introduced `channelKeyFallback(channelKeyFallback: Boolean)` * Remove redundant already `noChannelKeyFallback()` option in the `NoFallbackAllowedTests` * Document the change and new behavior
* GH-3946: Revise Router channelKeyFallback option Fixes #3946 The `AbstractMappingMessageRouter` has both `resolutionRequired` and `channelKeyFallback` as `true` by default. End-users expects them to back off when they set a `defaultOutputChannel`. They really want something similar to Java `switch` statement * Change the logic in the `AbstractMappingMessageRouter` to reset `channelKeyFallback` to `false` when `defaultOutputChannel` to avoid attempts to resolve channel from name, but rather fallback to `defaultOutputChannel` as it states from th mentioned Java `switch` statement experience * Deprecate `RouterSpec.noChannelKeyFallback()` in favor of newly introduced `channelKeyFallback(boolean)` * Call `channelKeyFallback(false)` from an overloaded `defaultOutputToParentFlow()` to reflect the mentioned expected behavior in Java DSL as well. * Respectively, deprecate `KotlinRouterSpec.noChannelKeyFallback()` wrapper in favor of newly introduced `channelKeyFallback(channelKeyFallback: Boolean)` * Remove redundant already `noChannelKeyFallback()` option in the `NoFallbackAllowedTests` * Document the change and new behavior * Fix `IntegrationGraphServerTests` to `setChannelKeyFallback(true)` explicitly * Remove not relevant `default-output-channel` from the `DynamicRouterTests-context.xml` * Reject an `AbstractMappingMessageRouter` configuration where `defaultOutputChannel` is provided and both `channelKeyFallback` & `resolutionRequired` are set to `true`. Such a state makes `defaultOutputChannel` as not reachable and may cause some confusions in target applications. * Remove `&` symbol from JavaDocs * Fix `boolean` expression for `AbstractMappingMessageRouter` configuration check * Fix `IntegrationGraphServerTests` for new router behavior * Improve language in docs
In what version(s) of Spring Integration are you seeing this issue?
5.1.4.RELEASE
Describe the bug
When creating an IntegrationFlow bean using
IntegrationFlows.from(CHANNEL)
, in theroute(Function<S, T> router, Consumer<RouterSpec<T, MethodInvokingRouter>> routerConfigurer)
method, when configuring the router mappings, the methoddefaultOutputToParentFlow()
does not what the documentation says it does.Example:
Given this Integration Flow definition:
The log will only get printed if
Order::getType
is null. This is contrary to the javadoc which says that:To Reproduce
Create a Spring project in Java 11, using Spring 5.3.20 and Spring Integration 5.1.4.RELEASE .
Create an IntegrationFlow bean using the default
IntegrationFlows.from()
method:Create a class called Order:
And an enum called OrderType:
And with everything setup correctly, send a message to CHANNEL of an
Order
withOrderType.TAKEAWAY
.Expected behavior
The
log()
at the end of theorderIntegrationFlow
will be called because thedefaultOutputToParent
reached a default state.** Actual behavior **
An Exception is thrown where TAKEAWAY is not found to be a proper CHANNEL name defined in the Spring Context. Only if Order::getOrderType returns null, then the
log()
function is called.Sample
A link to a GitHub repository with a minimal, reproducible sample.
Reports that include a sample will take priority over reports that do not.
At times, we may require a sample, so it is good to try and include a sample up front.
The text was updated successfully, but these errors were encountered: