On Mar 31, 2009, at 10:47 AM, Paul Sandoz wrote:
>
>> All of this would be, I think, acheivable in an easy way (without
>> requiring the returning of anonymous subclasses) if
>> MessageBodyWriter had another parameter that would receive the
>> return type of the resource method, e.g. "Type
>> resourceMethodReturnType", similar to how "annotations" receives
>> it's annotations:
>>
>> boolean isWriteable(
>> java.lang.Class<?> type,
>> java.lang.reflect.Type genericType,
>> java.lang.annotation.Annotation[] annotations,
>> java.lang.reflect.Type resourceMethodReturnType, /* NEW */
>> MediaType mediaType)
>>
>> This would be analogous to genericType parameter in
>> MessageBodyReader, which receives the type of the parameter. It
>> would differ from genericType in MessageBodyWriter in that it would
>> always get the return type of the method and never do runtime
>> inspection, but instead let the provider infer the type on its own.
>> Basically doing less than what is done now for genericType.
>>
>> If you look at table 3.1 of the spec, you'll see that columns 2, 3
>> and 4 are available to MessageBodyWriter, but the first one really
>> isn't, which is exactly what resourceMethodReturnType would provide.
>>
>> What do you think?
>>
>
I'm confused, doesn't the genericType parameter give you exactly what
you need if you define your own generic response type ?
> Responses may also be "returned" by throwing exceptions. Thus the
> introduction of a new parameter specific to a resource method, which
> will not apply in all cases, introduces an inconsistency.
>
> IMHO given the inconsistency and the anonymous class work around i
> do not think there is enough justification to change the API.
>
> Now, if you could solve the builder problem to build a generic
> response (safely according to the type) then that would be something
> to consider in terms of changing the API.
>
+1.
Marc.