users@jersey.java.net

[Jersey] Re: InvocationException

From: Luis Gervaso <luis_at_woorea.es>
Date: Fri, 22 Jun 2012 17:09:58 +0200

Hi,

I've tried your suggestions with no success (see the log below my email)

If I catch the invocationException there is no way to get the entity since

readEntity() does not work outside request context

What i want is throw a MyException from the fault payload

new MyException(500, "Not Authorized", "You are not authorized to perform
the requested action: admin_required")


Jun 22, 2012 5:02:45 PM org.glassfish.jersey.filter.LoggingFilter log

INFO: 1 * LoggingFilter - Request received on thread main

1 > GET http://192.168.1.38:35357/v2.0/tenants

1 > Accept: application/json

1 > X-Auth-Token: 09b25a95ddc84869834a9083b5393bea


Jun 22, 2012 5:02:45 PM org.glassfish.jersey.filter.LoggingFilter log

INFO: 2 * LoggingFilter - Response received on thread main

2 < 403

2 < Vary: X-Auth-Token

2 < Date: Fri, 22 Jun 2012 15:03:33 GMT

2 < Content-Length: 136

2 < Content-Type: application/json

2 < Connection: keep-alive

{"error": {"message": "You are not authorized to perform the requested
action: admin_required", "code": 403, "title": "Not Authorized"}}


InvocationException{message=org.glassfish.jersey.client.InboundJaxrsResponse_at,
response=org.glassfish.jersey.client.InboundJaxrsResponse_at_71a2f5b1}



On Thu, Jun 14, 2012 at 5:48 PM, Marek Potociar
<marek.potociar_at_oracle.com>wrote:

> Hi,
>
> It's an interesting idea, yet I'm not sure I see the advantage.
>
> Here's what you should be able to do (eventually) without an exception
> being thrown regardless of the response status code:
>
> // does not throw WebApplicationException if status is not 2xx
> Response res = target.request(MediaType.APPLICATION_JSON).get();
> String content = res.readEntity(String.class);
>
> Or, if you don't care about status codes:
>
> // does not throw WebApplicationException if status is not 2xx
> String content
> = target.request(MediaType.APPLICATION_JSON).get().readEntity(String.class);
>
> as opposed to:
>
> // throws WebApplicationException if status is not 2xx
> String content
> = target.request(MediaType.APPLICATION_JSON).get(String.class);
>
> Alternatively, you can use the same-root exception hierarchy we plan to
> introduce to process exceptional response status codes:
>
> String content;
> try {
> content = target.request(MediaType.APPLICATION_JSON).get(String.class);
> } catch (WebApplicationException ex) {
> // process all error status codes
> }
>
> or more fine-grained, e.g.:
>
> String content;
> try {
> content = target.request(MediaType.APPLICATION_JSON).get(String.class);
> } catch (RedirectionException ex) {
> // Process 3xx errors (with a support for redirect on the exception)
> } catch (ClientErrorException ex) {
> // Process 4xx errors
> } catch (ServerErrorException ex) {
> // Process 5xx errors
> }
>
> I agree that the proposal is more verbose compared to your suggestion. But
> it is IMO also more universal and simpler to specify and use.
>
> Marek
>
> On Jun 14, 2012, at 2:34 PM, Luis Gervaso wrote:
>
> Hi,
>
> Thanks, I understand.
>
> Let me explain my use case:
>
> From client i tried to invoke a operation and a server fault is returned.
> For example this can be an HTTP 500 Internal Server Exception.
> In the payload i have JSON/XML i want to parse in order to get more info
> on the client side about the exception and convert it to a client
> known exception, for example: ClientKnownException("Detailed message from
> JSON payload")
>
> I think it can be done for example
>
> target.request(MediaType.APPLICATION_JSON).expectedException(ClientKnownException,
> 500, 503).get()
>
> where
>
> exepectedException(Throwable t, int... codes) {
>
> }
>
> Luis
>
> On Thu, Jun 14, 2012 at 12:03 AM, Marek Potociar <
> marek.potociar_at_oracle.com> wrote:
>
>> Hi,
>>
>> we are currently working in the JAX-RS expert group on revisiting the
>> proposed exception hierarchy. The general idea is something like this:
>>
>>
>> 1. Client-side exceptions will be wrapped into an InvocationException
>> and rethrown. Invocation exception will not have the Response anymore.
>> 2. Server-side error responses will be converted to a subclass of the
>> WebApplicationException only in case the user tries to directly convert the
>> response entity to a Java type, e.g.:
>>
>> String content = client.target(...).request().get(String.class) // may
>> throw WAE
>>
>>
>> This is to make sure users don't confuse error responses for normal ones
>> during response content processing. To avoid the exception in the case #2,
>> a user could access the whole Response instance instead:
>>
>> Response response = client.target(...).request().get();
>> String content = response.readEntity(String.class); // does not throw WAE
>>
>> In the case above, an exception will not be thrown as it is expected the
>> user can check the response status to make sure the response is not an
>> error.
>>
>> Alas, the above is not yet implemented in Jersey as well as the problem
>> with the request context is not fixed yet. We should have it fixed in a few
>> weeks.
>>
>> Stay tuned,
>> Marek
>>
>> On Jun 11, 2012, at 5:15 PM, Luis Gervaso wrote:
>>
>> Hi,
>>
>> What is the recommended way to handle InvocationException on the client
>> side?
>>
>> Every Error Response comes to me with an error description in the
>> response entity.
>>
>> 1) If i handle on a filter:
>>
>> throw readEntity(CustomException.class)
>>
>> is wrapped with an InvocationException
>>
>> 2) if i handle on my client
>>
>> I can not perform readEntity since I'm not in a request context
>>
>> Any clues?
>>
>> Regards
>>
>>
>> --
>> -------------------------------------------
>> Luis Alberto Gervaso Martin
>> Woorea Solutions, S.L
>> CEO & CTO
>> mobile: (+34) 627983344
>> luis@ <luis.gervaso_at_gmail.com>woorea.es
>>
>>
>>
>
>
> --
> -------------------------------------------
> Luis Alberto Gervaso Martin
> Woorea Solutions, S.L
> CEO & CTO
> mobile: (+34) 627983344
> luis@ <luis.gervaso_at_gmail.com>woorea.es
>
>
>


-- 
-------------------------------------------
Luis Alberto Gervaso Martin
Woorea Solutions, S.L
CEO & CTO
mobile: (+34) 627983344
luis@ <luis.gervaso_at_gmail.com>woorea.es