On Jun 5, 2008, at 4:07 PM, Stephan Koops wrote:
>
> WebApplicationException
> Is a runtime envirnoment allowed to throw subclasses of
> WebAppExceptions in the matching algorithms given by the spec, if
> the spec requires a WebApplicationException? This subclasses could
> contain additional attributes for data that is useful for a message
> generation. I've also seen subclasses of WebAppExc in the Jersey API
> or SPI. But the runtime environment must not provide special
> excpetion mappers for them, because an exception mapper given by the
> user for WebApplicationException would not be reached.
>
I can't see any reason why a runtime shouldn't be allowed to throw a
subclass of WebApplictionException but the first bullet of 3.3.4 would
need to be updated to be explicit about this. The second bullet
already allows an exception mapping provider for a superclass to be
used if one isn't available for the actual exception so I don't see
why we couldn't do the same for WebApplicationException.
> genericType for the MessageBodyWriter
> The last days we discuss a way to provide the generic type to the
> MessageBodyWriter. I don't understand why I can't reflect the
> method. I could do it the same way I've do it, if a
> JAXBElement<Person> is returned (or whatever generic there is). Or
> where whould I get it from in this case? Dhanji argued right, that
> this has risks, e.g. that you could only return one generic type
> here, but there is no more information available. Where should I get
> this information from, if not by reflections?
>
You can reflect the method if it returns a generic type, e.g.:
@GET
List<String> get() {...}
However, due to type erasure, you can't reflect a returned instance so
if its wrapped in a Response or if the method is less informative then
you lose the generic type information, e.g.:
@GET
Object get() {...}
@GET
Response get() {...}
Even if the same instance is returned in all three method, reflection
of the instance would give List<?> instead of List<String>. This is OK
if you have a loose MessageBodyReader that will handle any List but
its an issue if you want to select the writer based on the generic
type. We want the same information to be available to the runtime
regardless of the return type. Otherwise you might get a different
MessageBodyWriter if you switch the return type of the method from
something specific to Response. The new GenericEntity class I just
checked in makes this possible. I'll be updating the spec to
explicitly define where the type and genericType values in
MessageBodyWriter.isWriteable come from for each of the possible
resource method return types.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.