ClassCastException after upgrade to Spring Boot 2.5-RC1

[agebhar1]

In what version(s) of Spring Integration are you seeing this issue?

5.5.0-RC1 via Spring Boot 2.5-RC1

Describe the bug

java.lang.ClassCastException: java.lang.String cannot be cast to org.springframework.messaging.Message
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_292]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_292]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_292]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_292]
        at org.springframework.integration.handler.LambdaMessageProcessor.processMessage(LambdaMessageProcessor.java:97) ~[spring-integration-core-5.5.0-RC1.jar:5.5.0-RC1]
        at org.springframework.integration.handler.ServiceActivatingHandler.handleRequestMessage(ServiceActivatingHandler.java:105) [spring-integration-core-5.5.0-RC1.jar:5.5.0-RC1]
        at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleMessageInternal(AbstractReplyProducingMessageHandler.java:134) [spring-integration-core-5.5.0-RC1.jar:5.5.0-RC1]

on handler method within integration flow.

Sample

https://github.com/agebhar1/spring-integration-kotlin-bug

The error does not occur if explicitly use Koltin 1.4(.32)

[artembilan]

Well, isn't that a problem in Kotlin then, rather than in Spring Integration?
Looks like Spring Boot exposes this one as a version for us kotlinVersion=1.5.0-RC.

In Spring Integration we have:

ext.kotlinVersion = '1.4.32'
...
compileKotlin {
		kotlinOptions {
			languageVersion = '1.3'
			jvmTarget = '1.8'
			freeCompilerArgs = ['-Xjsr305=strict']
			allWarningsAsErrors = true
		}
}

This is exactly aligned with Spring Framework: https://github.com/spring-projects/spring-framework/blob/main/build.gradle#L4.

Meanwhile I'm adding your test into the project for more coverage.
And probably I'll try to compile it with that kotlinVersion=1.5.0-RC...

BTW, haven't you tried with the latest Kotlin SNAPSHOT? Might be very the case that there is something was fixed around reflection...

[artembilan]

While copying your sample, I'd suggest you take a look into a Kotlin DSL we provide in Spring Integration: https://docs.spring.io/spring-integration/docs/current/reference/html/kotlin-dsl.html#kotlin-dsl

[agebhar1]

Thanks @artembilan for your fast reply. I also think the problem is in Kotlin 1.5-RC. The dependency to Kotlin 1.5-RC comes from Spring Boot spring-boot-dependencies-2.5.0-RC1

<kotlin.version>1.5.0-RC</kotlin.version>

Yes I tried the latest SNAPSHOT (removed the local .m2 directory).

Thank you for the hint to the Kotlin DSL.

[artembilan]

Well, this one .handle { message: Message<String>, _ -> message.also { println(it.payload) } } indeed leads to that ClassCastException. See docs: https://docs.spring.io/spring-integration/docs/current/reference/html/dsl.html#java-dsl-class-cast.

So, it's probably a bug in the current Kotlin 1.4.x since we haven't caught it before.
What I see from debug that this Kotlin lambda is not a Java lambda and we end up in the else block:

		if (ClassUtils.isLambda(handler.getClass())) {
			serviceActivatingHandler = new ServiceActivatingHandler(new LambdaMessageProcessor(handler, payloadType));
		}
		else {
			serviceActivatingHandler = new ServiceActivatingHandler(handler, ClassUtils.HANDLER_HANDLE_METHOD);
		}

Therefore something indeed was changed in Kotlin 1.5 to make us happy in Java world.
Try this one as a recommended fix for this kind of use-cases:

.handle(Message::class.java) { message, _ -> message.also { println(it.payload) } }

I'm still looking into Kotlin 1.5 😄

[agebhar1]

Oh 😱 - thanks a lot for the suggested fix 👍

[agebhar1]

With the transformer part it's the same problem:

	public <P, T> B transform(Class<P> payloadType, GenericTransformer<P, T> genericTransformer,
			Consumer<GenericEndpointSpec<MessageTransformingHandler>> endpointConfigurer) {

		Assert.notNull(genericTransformer, "'genericTransformer' must not be null");
		Transformer transformer = genericTransformer instanceof Transformer ? (Transformer) genericTransformer :
				(ClassUtils.isLambda(genericTransformer.getClass())
						? new MethodInvokingTransformer(new LambdaMessageProcessor(genericTransformer, payloadType))
						: new MethodInvokingTransformer(genericTransformer, ClassUtils.TRANSFORMER_TRANSFORM_METHOD));
		return addComponent(transformer)
				.handle(new MessageTransformingHandler(transformer), endpointConfigurer);
	}

[artembilan]

So, yes, something has changed in Kotlin 1.5 and we have true now for a Kotlin class being lambda:

class io.github.agebhar1.SpringIntegrationKotlinTests$Configuration$$Lambda$688/0x0000000800eb7840
...
public static boolean isLambda(Class<?> aClass) {
	return aClass.isSynthetic() && !aClass.isAnonymousClass() && !aClass.isLocalClass();
}

Therefore the fix I suggest with an extra type argument for Message::class.java is the way to go.
And since we have that covered in the docs, I'm inclined to close this issue as Works as Designed.

Your transformer logic to just copy headers is redundant: if you return just a payload, the framework will create a message for you and copy request headers, respectively.

[agebhar1]

Okay to fix the test with Kotlin 1.5-RC is to change the flow like this:

        @Bean
        fun flow(): StandardIntegrationFlow =
                from(input())
                        .handle(Message::class.java) { message, _ -> message.also { println(it.payload) } }
                        .transform(object : AbstractTransformer() {
                            override fun doTransform(message: Message<*>): Any {
                                return MessageBuilder.withPayload((message.payload as String).toUpperCase())
                                        .copyHeaders(message.headers)
                                        .build()
                            }
                        })
                        .channel(output())
                        .get()

The header in the transform part is used in the real code.

I'm fine with closing the issue. Maybe some hint should be added in either the Spring Boot or Spring Integration upgrade documentation.

Thank you!

[artembilan]

Thanks for confirmation!

I don't think there is needed some hint, since we have that doc already pointing for the reason of such a ClassCastException.
Plus, it is indeed recommended to use an idiomatic Kotlin DSL instead. 😄