Skip to content
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

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

Closed
spring-issuemaster opened this issue Dec 1, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Dec 1, 2017

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:

  • #21029 JsonMappingException when trying to instantiate org.springframework.messaging.Message

Referenced from: commits 583201b, 6dbc828

Backported to: 4.3.14

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 13, 2017

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 13, 2017

Juergen Hoeller commented

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

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 4, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.