ResponseProcessingException with no information

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ResponseProcessingException with no information

Robert DiFalco
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]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ResponseProcessingException with no information

Pavel Bucek-2
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]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ResponseProcessingException with no information

Robert DiFalco
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 <[hidden email]> 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]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ResponseProcessingException with no information

Robert DiFalco
Here's the complete stack trace. I'm just not sure how it could not be showing a cause. 

javax.ws.rs.client.ResponseProcessingException
  at org.glassfish.jersey.client.JerseyInvocation.translate(JerseyInvocation.java:869) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at org.glassfish.jersey.client.JerseyInvocation.access$800(JerseyInvocation.java:92) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at org.glassfish.jersey.client.JerseyInvocation$3.call(JerseyInvocation.java:722) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at org.glassfish.jersey.internal.Errors.process(Errors.java:315) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at org.glassfish.jersey.internal.Errors.process(Errors.java:297) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at org.glassfish.jersey.internal.Errors.process(Errors.java:228) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:444) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:718) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:430) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at org.glassfish.jersey.client.JerseyInvocation$Builder.get(JerseyInvocation.java:321) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.tags.client.TagsClient.organizationMappings(TagsClient.java:58) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.collector.TagsManager.getMappings(TagsManager.java:62) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.collector.TagsManager.lambda$createContext$7(TagsManager.java:56) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.collector.TagsManager.measure(TagsManager.java:132) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.collector.TagsManager.createContext(TagsManager.java:50) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.billing.processing.aws.AwsBillProcessor.parseXyz(AwsBillProcessor.java:109) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.billing.processing.aws.AwsBillProcessor.process(AwsBillProcessor.java:92) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.billing.processing.aws.AwsBillProcessor.accept(AwsBillProcessor.java:74) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.billing.processing.aws.AwsBillProcessor.accept(AwsBillProcessor.java:31) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.common.sqs.SQSLeasedMessageConsumerService.process(SQSLeasedMessageConsumerService.java:234) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.common.sqs.SQSLeasedMessageConsumerService.lambda$process$35(SQSLeasedMessageConsumerService.java:190) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_66]
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_66]
  at java.lang.Thread.run(Thread.java:745) [?:1.8.0_66]

On Fri, Feb 19, 2016 at 3:57 PM, Robert DiFalco <[hidden email]> 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 <[hidden email]> 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]



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ResponseProcessingException with no information

Gili
In reply to this post by Robert DiFalco
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 <[hidden email]> 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]



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ResponseProcessingException with no information

Robert DiFalco
In reply to this post by Robert DiFalco
The only explanation I can think of is that in this line ex.getCause() returns null, meaning that ex is the important part and not ex.getCause().

} catch (final ProcessingException ex) {
throw new ResponseProcessingException(new InboundJaxrsResponse(response, scope), ex.getCause());

On Fri, Feb 19, 2016 at 4:01 PM, Robert DiFalco <[hidden email]> wrote:
Here's the complete stack trace. I'm just not sure how it could not be showing a cause. 

javax.ws.rs.client.ResponseProcessingException
  at org.glassfish.jersey.client.JerseyInvocation.translate(JerseyInvocation.java:869) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at org.glassfish.jersey.client.JerseyInvocation.access$800(JerseyInvocation.java:92) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at org.glassfish.jersey.client.JerseyInvocation$3.call(JerseyInvocation.java:722) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at org.glassfish.jersey.internal.Errors.process(Errors.java:315) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at org.glassfish.jersey.internal.Errors.process(Errors.java:297) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at org.glassfish.jersey.internal.Errors.process(Errors.java:228) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:444) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:718) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:430) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at org.glassfish.jersey.client.JerseyInvocation$Builder.get(JerseyInvocation.java:321) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.tags.client.TagsClient.organizationMappings(TagsClient.java:58) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.collector.TagsManager.getMappings(TagsManager.java:62) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.collector.TagsManager.lambda$createContext$7(TagsManager.java:56) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.collector.TagsManager.measure(TagsManager.java:132) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.collector.TagsManager.createContext(TagsManager.java:50) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.billing.processing.aws.AwsBillProcessor.parseXyz(AwsBillProcessor.java:109) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.billing.processing.aws.AwsBillProcessor.process(AwsBillProcessor.java:92) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.billing.processing.aws.AwsBillProcessor.accept(AwsBillProcessor.java:74) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.billing.processing.aws.AwsBillProcessor.accept(AwsBillProcessor.java:31) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.common.sqs.SQSLeasedMessageConsumerService.process(SQSLeasedMessageConsumerService.java:234) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at com.XXXX.pipeline.common.sqs.SQSLeasedMessageConsumerService.lambda$process$35(SQSLeasedMessageConsumerService.java:190) ~[foo-bar-1.32-SNAPSHOT.jar:1.32-SNAPSHOT]
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_66]
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_66]
  at java.lang.Thread.run(Thread.java:745) [?:1.8.0_66]

On Fri, Feb 19, 2016 at 3:57 PM, Robert DiFalco <[hidden email]> 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 <[hidden email]> 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]




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ResponseProcessingException with no information

Robert DiFalco
In reply to this post by Gili
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 <[hidden email]> 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 <[hidden email]> 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]




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ResponseProcessingException with no information

Robert DiFalco
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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]





Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ResponseProcessingException with no information

Pavel Bucek-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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]






Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ResponseProcessingException with no information

Robert DiFalco
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email][hidden email]> 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 <[hidden email][hidden email]> 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]







Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ResponseProcessingException with no information

Robert DiFalco
Scratch that, the server is not streaming. 

On Tue, Feb 23, 2016 at 3:26 PM, Robert DiFalco <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email][hidden email]> 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 <[hidden email][hidden email]> 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]








Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ResponseProcessingException with no information

Robert DiFalco
I think the shaded jar must be messing something up and that's why it works locally for me but the deployed jar does not work. What kind of dependency issue would cause a ResponseProcessorException to be created with OUT a cause exception or message? I really wish that exception was constructed with "ex" as it's cause instead of "ex.getCause()". :)

Some more info, if I change the client to get a String.class and then use my own JSON mapper it works fine.  So it definitely seems to have something to do with client deps. IOW, this works:

String json = target.request().get(String.class);
log.debug("GOT: {}", json);
return JsonUtils.toObject(json, new TypeReference<List<Mapping>>(){});
While this does not work:
return target.request().get(new GenericType<List<Mapping>>(){});
Weird that the exception doesn't provide more info huh? 

R.


On Tue, Feb 23, 2016 at 3:32 PM, Robert DiFalco <[hidden email]> wrote:
Scratch that, the server is not streaming. 

On Tue, Feb 23, 2016 at 3:26 PM, Robert DiFalco <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email][hidden email]> 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 <[hidden email][hidden email]> 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]









Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ResponseProcessingException with no information

Marshall Pierce
It may be that the shading process is mangling the files that ServiceLocator or some similar mechanism is using to find stuff at runtime.

> On Feb 23, 2016, at 4:24 PM, Robert DiFalco <[hidden email]> wrote:
>
> I think the shaded jar must be messing something up and that's why it works locally for me but the deployed jar does not work. What kind of dependency issue would cause a ResponseProcessorException to be created with OUT a cause exception or message? I really wish that exception was constructed with "ex" as it's cause instead of "ex.getCause()". :)
>
> Some more info, if I change the client to get a String.class and then use my own JSON mapper it works fine.  So it definitely seems to have something to do with client deps. IOW, this works:
>
> String json = target.request().get(String.class);
> log.debug("GOT: {}", json);
> return JsonUtils.toObject(json, new TypeReference<List<Mapping>>(){});
> While this does not work:
> return target.request().get(new GenericType<List<Mapping>>(){});
> Weird that the exception doesn't provide more info huh?
>
> R.
>
>
> On Tue, Feb 23, 2016 at 3:32 PM, Robert DiFalco <[hidden email]> wrote:
> Scratch that, the server is not streaming.
>
> On Tue, Feb 23, 2016 at 3:26 PM, Robert DiFalco <[hidden email]> wrote:
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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]
>>>
>>>
>>
>>
>>
>
>
>
>

Loading...