[
https://issues.apache.org/jira/browse/JENA-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15970181#comment-15970181
]
ASF GitHub Bot commented on JENA-1321:
--------------------------------------
Github user rmorrise commented on the issue:
https://github.com/apache/jena/pull/240
That works. Personally I prefer to see the original root cause but I guess
people sometimes get distracted by long stack traces. If you are going to do
that can you check the original exception's hierarchy for other props that
might be needed like headers etc.?
> Exception rewrapping in HttpQuery masks error response from the server
> ----------------------------------------------------------------------
>
> Key: JENA-1321
> URL: https://issues.apache.org/jira/browse/JENA-1321
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
> Affects Versions: Jena 3.2.0
> Environment: Client: Grails 3.2.8, Windows 7
> Server: Oracle Joseki server on Tomcat 8 (RHEL)
> Reporter: Russell Morrisey
> Original Estimate: 20m
> Remaining Estimate: 20m
>
> When the SPARQL server responds to a request with an error (e.g. 500 error),
> the Tomcat error response body provides detailed information about what went
> wrong. This response information is included in the underyling HttpException,
> but is being masked by faulty error handling code in
> org.apache.jena.sparql.engine.http.HttpQuery.
> The rewrap() method should specify httpEx as the root cause of the exception,
> not httpEx.getCause(). This will ensure that the response body information is
> preserved.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
