[
https://issues.apache.org/jira/browse/DERBY-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14606301#comment-14606301
]
ASF subversion and git services commented on DERBY-6820:
--------------------------------------------------------
Commit 1688297 from [~bryanpendleton] in branch 'code/trunk'
[ https://svn.apache.org/r1688297 ]
DERBY-6820: Improve error handling in XmlVTI
This patch refines some of the error-handling behavior in the XmlVTI class:
- next() no longer calls printStackTrace if an exception is encountered.
- the SQLException thrown by next() now chains the original exception as cause
- an XMLErrorHandler is installed to process any internal parsing errors
- the XMLErrorHandler closes the input source, so resources can be freed
No new tests are included in this change. Additional new tests which exercise
these code paths are being developed as part of DERBY-6810, however, and
will be submitted in the near future.
> Improve error handling in XmlVTI
> --------------------------------
>
> Key: DERBY-6820
> URL: https://issues.apache.org/jira/browse/DERBY-6820
> Project: Derby
> Issue Type: Sub-task
> Components: SQL
> Affects Versions: 10.11.1.1
> Reporter: Bryan Pendleton
> Assignee: Bryan Pendleton
> Attachments: errorHandling.diff
>
>
> While writing XXE vulnerability test suites for XmlVTI, I found that
> some of the error handling logic in XmlVTI is a bit rough and could
> be made a bit smoother.
> At least the following improvements would be useful:
> 1) Remove the unconditional printStackTrace call in XmlVTI.next()
> when it catches a Throwable.
> 2) Chain the original exception to the SQLException using the
> SQLException constructor which takes a "cause" argument.
> 3) Include an XMLErrorHandler class so that fatal exceptions that
> arise within the XML parser don't directly print their own messages
> to System.err, to avoid printing
> [junit] [Fatal Error] :1:1: The parser has encountered more than "64,000"
> entity expansions in this document; this is the limit imposed by the
> application.
> 4) Close the _xmlResource input stream, if it exists, from the
> XMLErrorHandler methods, so that the parser's files are closed
> sooner and we are (I think) less likely to encounter
> [junit] <assertDirectoryDeleted> attempt 1 left 2 files/dirs behind:
> 0=extin\xmlOptimizerXXE2.trace 1=extin
> [junit] <assertDirectoryDeleted> attempt 2 left 2 files/dirs behind:
> 0=extin\xmlOptimizerXXE2.trace 1=extin
> [junit] <assertDirectoryDeleted> attempt 3 left 2 files/dirs behind:
> 0=extin\xmlOptimizerXXE2.trace 1=extin
> [junit] <assertDirectoryDeleted> attempt 4 left 2 files/dirs behind:
> 0=extin\xmlOptimizerXXE2.trace 1=extin
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
