Marc Hadley wrote:
> On Sep 29, 2008, at 11:54 AM, Reto Bachmann-Gmür wrote:
>>>>
>>> Hmm, not sure if I understand you. You need to call the isWritable
>>> method at least once for each distinct combination of type, generic
>>> type, annotations and supported media type to determine if the writer
>>> is able to serialize the entity.
>> If we call isWritable with the declared type (and not with the type of
>> the object actually returned) we can identify all possible
>> method-writer pairs that would generate an acceptable response.
>
> The type argument of the isWritable method is the class of the instance,
> not of the method return type. If a method returns Response you don't
> statically know what you'll get for an entity. It would be weird if you
> got different writers for the same depending on the resource method
> return type.
To me its not obvious which behavior is weirder. Say we have an
Interface Person, an interface FootbalPlayer with respective writers and
a resource method
//returns the candidate
@GET
Person getCandidate() {
return PersonDataBase.getPerson(....);
}
If the relevant type is the returned type it will always be rendered the
same way, if its the class of the returned instance it will be rendered
differently if the candidate happens to be a FootballPlayer. It depends
on the situation which behavior is wanted. But enforcing the other
behavior is of different complexity. If we use the class of the instance
and the getCandidate method wants to enforce sub-type independent
rendering it has to wrap the value returned by PersonDataBase.getPerson
which may not always be possible (i.e. it might need an extra class and
an extra writer), on the other hand, if the application wants dynamism
in a scenario where the declared return type is relevant (as in the
patch I proposed for issue 46) the resource method would only have to
return Response or GenericEntity.
Reto