Exception when receiving Long collection in MessageMapping [SPR-16252]

[spring-projects-issues]

Jhovanni opened SPR-16252 and commented

When you try to receive a collection of Long values, as parameter of a MessageMapping method (from spring messaging), you can print the collection. But if you try to access its values, there is an exception throw about not being able to cast Integer to Long.

Replicate it is easy:

@MessageMapping("/channel")
public void receiveLongs(List<Long> list) {
for (Long value : list) {
System.out.println("Line above throws java.lang.ClassCastException");
}
}
Exception throw is java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long.
Code found in github repository is ready to be used and replicate the bug.

---

Affects: 4.3.12

Reference URL: https://github.com/Jhovanni/LongException

Issue Links:

• JsonMappingException when trying to instantiate org.springframework.messaging.Message [SPR-16486] #21029 JsonMappingException when trying to instantiate org.springframework.messaging.Message

Referenced from: commits 583201b, 6dbc828

Backported to: 4.3.14

[spring-projects-issues]

Rossen Stoyanchev commented

Juergen Hoeller this is fixed in master but the backport will require this GenericTypeResolver method introduced in 5.0. Or alternatively duplicating what's in AbstractJackson2HttpMessageConverter#getJavaType on the 4.3.x branch.

[spring-projects-issues]

Juergen Hoeller commented

Alright, I'll care for the backport then, making up my mind on GenericTypeResolver...

[spring-projects-issues]

Rossen Stoyanchev commented

Juergen Hoeller I've taken the first step to backporting by copying the code required to obtain the Java Type. That way you can still decide to do the GenericTypeResolver refactoring as an extra step but this issue can be resolved irrespective of that.

It would be very easy to add a getJavaType method to GenericTypeResolver and maybe that's sufficient as a compromise for 4.3.x. However I noticed that in 5.0 you also removed some overlap with another existing method in GenericTypeResolver. So I'll leave it to you to decide the exact further changes to make.