users@jersey.java.net

[Jersey] Re: ResponseProcessingException with no information

From: Robert DiFalco <robert.difalco_at_gmail.com>
Date: Tue, 23 Feb 2016 15:26:05 -0800

Sorry Pavel I cannot, but the recent information I got is that this
succeeds from me when I am running it on my local development machine (as a
client to the prod server) but when the client runs from a VPC EC2 instance
it fails in this weird way.

The other thing is that the server is a jersey server using async to stream
it's GET response to the client.

On Tue, Feb 23, 2016 at 3:27 PM, Pavel Bucek <pavel.bucek_at_oracle.com> wrote:

> can you to extract this into minimal reproducer?
>
> (I'd need to attach debugger to see what is going on, just the stacktrace
> does not help in this case, sorry ;-/
>
>
> On 24/02/16 00:07, Robert DiFalco wrote:
>
> Any thoughts on this? I'm assuming there may be a dependency issue but
> truly the cause is null so it's hard to figure out what I am doing wrong.
>
> On Fri, Feb 19, 2016 at 4:03 PM, Robert DiFalco <robert.difalco_at_gmail.com>
> wrote:
>
>> No, Gili, it's just regular old log4j and it doesn't strip out the cause.
>>
>> On Fri, Feb 19, 2016 at 4:01 PM, cowwoc < <cowwoc_at_bbs.darktech.org>
>> cowwoc_at_bbs.darktech.org> wrote:
>>
>>> If you are reproducing this in Surefire, it will strip out the cause.
>>> See
>>> http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#trimStackTrace
>>>
>>> Newer versions of Surefire do a better job of not stripping out the
>>> cause in more cases but I still disable this feature when I run into
>>> problems, just to be safe.
>>>
>>> Gili
>>>
>>>
>>> On 2016-02-19 6:57 PM, Robert DiFalco wrote:
>>>
>>> Odd, it certainly seems like it from my logging. I have yet to reproduce
>>> it in a debugger. But we just do a simple log.error("Unexpected error.", e)
>>> on that exception. For all other exceptions this will typically also print
>>> out the cause.
>>>
>>> On Fri, Feb 19, 2016 at 3:49 PM, Pavel Bucek < <pavel.bucek_at_oracle.com>
>>> pavel.bucek_at_oracle.com> wrote:
>>>
>>>> Hi Robert,
>>>>
>>>> are you sure there is no "cause" set for this exception?
>>>>
>>>> Regards,
>>>> Pavel
>>>>
>>>>
>>>> On 20/02/16 00:36, Robert DiFalco wrote:
>>>>
>>>> I'm getting this exception with no message and no caused by. This is
>>>> just calling a GET method. Simple app using latest Jersey Client and
>>>> Jackson. The stack trace is here:
>>>>
>>>> javax.ws.rs.client.ResponseProcessingException
>>>> at
>>>> org.glassfish.jersey.client.JerseyInvocation.translate(JerseyInvocation.java:869)
>>>> ~[XXXX-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
>>>> at
>>>> org.glassfish.jersey.client.JerseyInvocation.access$800(JerseyInvocation.java:92)
>>>> ~[XXXX-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
>>>> at
>>>> org.glassfish.jersey.client.JerseyInvocation$3.call(JerseyInvocation.java:722)
>>>> ~[XXXX-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
>>>> at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
>>>> ~[XXXX-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
>>>> at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
>>>> ~[XXXX-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
>>>> at org.glassfish.jersey.internal.Errors.process(Errors.java:228)
>>>> ~[XXXX-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
>>>> at
>>>> org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:444)
>>>> ~[XXXX-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
>>>> at
>>>> org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:718)
>>>> ~[XXXX-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>