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

Add possibility to set supportedMimeTypes in MappingJackson2MessageConverter [SPR-12724] #17321

Closed
spring-issuemaster opened this issue Feb 17, 2015 · 3 comments

Comments

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

commented Feb 17, 2015

Tomasz Krym opened SPR-12724 and commented

It is possible to use Jackson API (annotations, ObjectMapper, etc.) with other formats than JSON (see reference URL), i.e. BSON, XML, Smile JSON. It is possible to configure MappingJackson2MessageConverter to use those JsonFactories, but it is not possible to configure supportedMediaTypes.

The possibility of setting supportedMediaTypes is explicitely blocked by declaring non parametrized constructor in MappingJackson2MessageConverter.

Adding a parametrized constructor would solve this issue.


Affects: 4.1.4

Reference URL: http://wiki.fasterxml.com/JacksonOutsideofJSON

Referenced from: commits 1dc3932, 8159aa9, 8716129

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 18, 2015

Sébastien Deleuze commented

Resolved by this commit and ready to be backported on the 4.1.x branch.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 18, 2015

Juergen Hoeller commented

A minor note: For concrete converter implementations such as MappingJackson2MessageConverter here, it seems to be preferable to provide a var-arg variant only, i.e. MappingJackson2MessageConverter(MimeType...), instead of separate single-arg and collection constructors, keeping the overall number of constructors to two and allowing for convenient var-arg use in application setup code.

The situation with AbstractMessageConverter is a bit different since it doesn't have a default content type at that level, and its constructors are not used in application code but only from subclass constructors... So the collection-based constructor variant is arguably worthwhile there, just not necessarily with application-level subclass constructors.

I'm applying this to master and to the backport, if that's alright with you, Sébastien...

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 18, 2015

Sébastien Deleuze commented

Yes, I fully agree with your point.

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.