On Apr 16, 2010, at 3:02 PM, Alex Treppass wrote:
> ContainerResponse.write() uses “application/octet-stream” as a
> default value to locate a MessageBodyWriter when it has been unable
> to locate a valid MessageBodyWriter (line 250). Instead it should
> throw a WebApplicationException for response code 415 (Unsupported
> Media). Currently the default value causes a WebApplicationException
> with response code 500, which doesn’t tell the client what was wrong
> with their request.
>
A 415 is related the consuming of a request entity not producing a
response entity, and thus is related to reading not writing.
http://greenbytes.de/tech/webdav/rfc2616.html#status.415
Do you mean 406 (Not Acceptable)?
> Note that if you annotate the web application method with
> @Consumes(“application/xml”) then a request for any other mime type
> will correctly return 415. However if we remove the annotation the
> request returns 500. The accepted mime types therefore seem to be
> tightly coupled with the interface at compile time. We would ideally
> like the accepted mime types to be coupled with the
> MessageBodyWriters at runtime, allowing the available data formats
> (e.g. xml, json, html, atom, rss, etc) to configurable (e.g. Spring
> wired).
>
MessageBodyWriters may choose not to define concrete media types e.g.
wild cards or support say application/*+xml.
Can you share some code or a reproducible test case? i want to
understand more about your set up and use of message body readers/
writers and @Produces.
Paul.