[
https://issues.apache.org/jira/browse/JENA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13398598#comment-13398598
]
Rob Vesse commented on JENA-236:
--------------------------------
Claude
If I understand correctly the problem you are encountering is that you make a
SERVICE call which succeeds but partway through fails due to malformed XML
(*cough* DBPedia) and this failure is a parser error rather than a query error?
The patch you have proposed does not really seem appropriate because it
introduces a coupling between the SPARQL XML parser and the query engine when
none is really necessary. A better approach is to wrap the iterator
QueryIterService with another iterator which can catch parser errors and turn
them into query errors instead. Possibly with some configurable non-default
parameter like you have proposed to just silently continue on regardless of the
parsing error.
I will take a look at taking this approach
> Allow Service XML Parsing error to cancel the query on a per query basis
> ------------------------------------------------------------------------
>
> Key: JENA-236
> URL: https://issues.apache.org/jira/browse/JENA-236
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
> Affects Versions: ARQ 2.9.0
> Environment: All
> Reporter: Claude Warren
> Assignee: Rob Vesse
> Labels: features
> Attachments: JENA-236-1.txt
>
>
> Currently an XML parsing error may occur on a hasNext() call on a Sparql
> service query. The result is that the entire query (not just the service
> call) fails.
> The goal of this improvement is to capture the XML parsing error and return
> false for the hasNext(). The result being that data errors will be silently
> ignored. This should be done on a per endpoint basis. Perhaps as an
> onParseErrorCancel flag.
> I think there is an interplay of several flags in this request:
> 1) SILENT service parameter. If silent is true should this also be true by
> default? (I think not, but perhaps a system setting to make that the case)
> 2) cancelAllowDrain. If the error occurs should the cancel flag be raised?
> (I think not, but again perhaps a per service call flag to enable this)
> 3) JENA-93 discusses changing cancelAllowDrain to be a per endpoint setting.
> If that is the case it may apply here as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
