On Mar 19, 2008, at 4:41 AM, Stephan Koops wrote:
> Sorry for third email, but I've see a problem to what I wrote:
> When we ever give the return type of the method, than we have the
> problem, that the MessageBodyWriter get sometimes
> javax.ws.rs.Response. So it causes trouble, if we giv the result
> type to the MessageBodyWriter. A null result also will result in 204
> by default. Because of that I propose to define: If an entity object
> is null, use no MessageBodyWriter, and return no message body.
Agree with null -> no message body writer. Bill had a use-case for
null though so I'd like to understand that better.
>
> I think, we can remove the Class parameter of
> MessageBodyWriter.writeTo(......) and isWriteable(...).
> Otherwise it need to be precised, what should happen if the object
> is null.
>
I think we need the Class parameter for both, even if only for the
sake of consistency.
Marc.
>
> Stephan Koops schrieb:
>> Hi,
>>
>> Bill anounced in issue 36 [1] rightly, that the class is needed to
>> the MessageBodyWriter. The argument is, that the returned object
>> may be null. This indicates, that the type given to
>> MessageBodyWriter.writeTo(., Class, ....) is the return type of the
>> resource method.
>> The javadoc of MessageBodyWriter.writeTo(., Class, ....) says, that
>> the class of the object to be written should be given here.
>> If the returned object is a subclass (or implementation) of the
>> returned type, this differs.
>>
>> Should here ever be the return type of the resource method be
>> given? Than you have to conform the javadoc a little bit.
>>
>> regards
>> Stephan
>>
>> [1] https://jsr311.dev.java.net/issues/show_bug.cgi?id=36
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.