Add media types to possible handler method params

[acogoluegnes]

The requested media types are now valid arguments for Spring MVC
controller methods. They are computed by the
ContentNegotiationManager (so using the HTTP Accept header).
Controllers can ask for the requested media types by adding
a Collection- or a List-typed method argument.

Issue: SPR-9980

I have signed and agree to the terms of the SpringSource Individual
Contributor License Agreement.

[rstoyanchev]

After some further thought, although the proposed solution is perfectly valid, I'm not sure that the end result is generally useful and should be encouraged. A major assumption I'm making is that the injected list of media types will ultimately be used to determine the response media type and that requires a fairly complex algorithm that takes into consideration the order of the requested media types, their specificity, and any quality parameters. All that information must then be intersected against the media types the application can produce, etc. etc. Consider for example the kinds of headers browsers send.

That said I'm open to considering specific use cases where injecting the requested media types could be helpful. That would at least allow documenting well when it is a good idea and when it is not.

[rstoyanchev]

Taking the case of stackoverflow question attached to the original JIRA ticket, I would recommend two methods, one with produces='application/json' and another with produces=application/xml'.
Admittedly this can lead to many additional methods if it occurs throughout. I've created a ticket to consider improving it.

[ahsanfz]

While this is an old issue, I think it is a genuine usecase and a viable alternative to the Variant mechanism (request.getVariant() call ) that can be found in Jersey implementations.

I am migrating an application from Jersey to Spring MVC and I stumbled upon this. For the language part in the Variant implementation, the LocaleResolver was a good alternative.

For the other 2 dimensions of MediaType and encoding that is found in the Jersey implementation, this seems a good fit.

In my case I want to write to a StreamingResponseBody and the old implementation was using Variants to determine encoding. The encoding was specified the the accept header (MediaType/MimeType) and the parameter portions contains the charset. Using the resolver above I can get the encoding here where I need to know if before so that I can specify the correct encoding that the client specified to write with in my OutputStream/Writer.

In my case I am using text/plain and the client can ask me various encoding in order of his preference and I can accomadate it in my Response.

Does that make sense?

I think this resolver belongs in Spring by default.

[snicoll]

@rstoyanchev do you think we should reconsider this based on the feedback above?