1) I've a service with several media type processors registered for the response (XmlProcessor, JsonProcessor, custom Atom processor)
2) On a request with "Accept: application/xml, ...", the XmlProcessor is selected to encode the response. However, the object instance (an iterator object) is not serializable, so an exception is throwed. Unexpectedly, the response is a "200
OK" with content-lenght = 0 and not a 500.
1) Why is the exception on the XmlProcessor being ignored?
2) What should be the desired behavior?
i) "500", because an exception was throwed inside a pipeline?
ii) "406", because the selected media type processor (the XmlProcessor) was unable to process the representation?
iii) Try another media type processor that handles an accepted media-type.
IMHO, the desired behavior should be iii)
One could ask why is the XmlProcessor registered, when the returned object instance is not XML serializable. It is true that one can use the HttpOperationDescription registration parameter to check if the XML serialization makes sense, however, this decision
process is not easily feasible (for instance, the operation return type may be void)