Kotlin DSL: handle(handler: (P, MessageHeaders) -> Any) endpoint should not require output channel if lambda returns void

[ikarsokolov]

Expected Behavior

handle<T> { payload, headers -> .. } should work without output channel configured if lambda returns void.
Like handle { message -> .. } currently does.

Current Behavior

integrationFlow(inputChannel) {
    wireTap {
        transform(Transformers.toJson(NODE))
        handle<ObjectNode> { payload, headers ->
            logger.debug(...)
        }
    }
    ...
}

throws DestinationResolutionException: no output-channel or replyChannel header available. While

integrationFlow(inputChannel) {
    wireTap {
        transform(Transformers.toJson(NODE))
        handle { message ->
            logger.debug(...)
        }
    }
    ...
}

works as intended.

Context
Now I am using this workaround, not sure if it is the best way to go:

handle<ObjectNode> { payload, headers ->
    logger.debug(...)
}
channel(nullChannel)

[artembilan]

Well, since your lambda doesn't return anything (because of void logger.debug()), but that function still expect from us Any as a return, Kotlin just plays smart and build for us kotlin.Unit into the return statement which essentially becomes as a reply payload.

For now it looks like we need to treat that kotlin.Unit in our reflectional method invocation code as a void and do nothing ans we do with the void.

If there are better ideas how to make this Kotlin stuff working, I'm fully open for suggestion.

Thanks.

[artembilan]

For more Kotlin background: https://medium.com/thoughts-overflow/kotlin-has-nothing-but-there-is-nothing-like-nothing-in-java-cab98e4f4d26

[artembilan]

See PR on the matter: #3346

[ikarsokolov]

@artembilan I think you nailed it.

Another possible idea I have is to add to DSL handle(handler: (P, MessageHeaders) -> Unit) but I think this is not possible because of the type erasure and the two handle functions will be shadowed.

[artembilan]

True.
I think we can live with my fix for a while.
We still need to have Java interoperability.