On Jan 7, 2009, at 6:56 PM, Craig McClanahan wrote:
> Paul Sandoz wrote:
>> Hi,
>>
>> The Jersey supplied message body readers throw
>> WebApplicationException which then thrown causes the client side to
>> throw a null pointer exception when the jersey-server module is not
>> present. This is because a Response.ResponseBuilder implementation
>> does not exist.
>>
> Isn't this exception caught by logic inside the client
> infrastructure, where we could do the right thing with it? Or am I
> not understanding the entire scenario?
Not currently. I was intending the exception in some form would be
passed to the client (UniformInterfaceException is not the right one,
it needs to be an exception that encapsulates an issue for malformed
responses processed by the client).
>
>> I think the right solution is for such readers to throw a
>> MessageBodyReaderException runtime exception which is then mapped
>> on the server side to a 400 client error response. Thus such an
>> exception on the client sid makes sense to the developer rather
>> than reusing WebApplicationException with dummy-based response
>> builder.
> Would MessageBodyReaderException be a subclass of
> WebApplicationException?
I wanted to avoid the use of WebApplicationException because it makes
use of Response.ResponseBuilder and an implementation is only
available when the jersey-server module is present in the class path.
If the client is used when the jersey-server module is not present
then currently we get a rather vague error when instantiating
WebApplicationException.
> That would be consistent with the spirit of what the spec says about
> providers -- they MAY throw WebApplicationException or IOException
> from the readFrom() method, but it's silent about any others.
>
> On the server side, shouldn't this be mapped to a 500, not a 400?
> It doesn't seem like the client's fault if the server accepted a
> request, but then had trouble parsing it because of a missing
> dependency or something.
I am referring to the case of the client processing a response entity
that is malformed.
If the client sends a malformed request entity then the server should
respond with a 400 (Client Error).
Paul.
>
>
> Craig
>
>>
>> This should apply to all the readers in core, atom, multipart etc
>> that are capable of detecting client errors.
>>
>> What do others think?
>>
>> Paul.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>