As I said, the suggestion I described is yet to be implemented. Also, there is an open bug that we need to fix wrt. making sure that Response.readEntity ensures an active request scope on the client side.
Marek
On Jun 22, 2012, at 5:09 PM, Luis Gervaso wrote:
> 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:
>>
>> Client-side exceptions will be wrapped into an InvocationException and rethrown. Invocation exception will not have the Response anymore.
>> 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_at_woorea.es
>>>
>>
>>
>>
>>
>> --
>> -------------------------------------------
>> Luis Alberto Gervaso Martin
>> Woorea Solutions, S.L
>> CEO & CTO
>> mobile: (+34) 627983344
>> luis_at_woorea.es
>>
>
>
>
>
> --
> -------------------------------------------
> Luis Alberto Gervaso Martin
> Woorea Solutions, S.L
> CEO & CTO
> mobile: (+34) 627983344
> luis_at_woorea.es
>