Marc Hadley wrote:
> So you'd have:
>
> public interface MessageBodyReader<T> {
> boolean isReadable(Class<?> type, Type genericType);
>
> T readFrom(Class<T> type, Type genericType, MediaType mediaType,
> MultivaluedMap<String, String> httpHeaders,
> InputStream entityStream) throws IOException;
> }
>
> Where type=getParameterType()[i] and
> genericType=getGenericParameterTypes()[i], where i is the index of the
> parameter that is the entity ?
>
Yes, i think we should also have:
getParameterAnnotations()[i]
as that would link in with using a message (body) reader for general
meta-data as well.
>>> Must a MessageBodyWriter/MessageBodyReader close the input / output
>>> stream? The Jersey providers does, but it is not requested in the
>>> specification or in the javadoc.
>>
>> Can you point to some code? I looked at all the providers in the
>> latest source and none of them close the InputStream or OutputStream
>> instance that is passed respectively to the readFrom or writeTo methods.
>>
>> The intent was that the providers should not have to close or flush
>> the stream and it would be the responsibility of the caller to do
>> that, including guarding against potential unintended side-effects if
>> the callee does close the stream.
>>
> I think we need to be explicit about this in the javadoc. What kind of
> side-effects would you expect if the callee did close the stream.
None. It is up to the supplier of the stream to ensure that no
side-effects happen.
> Do we
> want "there's no need to close the stream" (implies you can but don't
> need to) or a "you must not close the stream" (implies things will break
> if you do).
>
I think the former.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109