Hi Aleksej,
Note that DOM spec about error handling: If errors occur during the
invocation of this method, such as an attempt to update a read-only node
or a |Node.nodeName| contains an invalid character according to the XML
version in use, errors or warnings (|DOMError.SEVERITY_ERROR| or
|DOMError.SEVERITY_WARNING|) will be reported using the
|DOMErrorHandler| object associated with the "error-handler " parameter.
Note this method might also report fatal errors (
|DOMError.SEVERITY_FATAL_ERROR|) if an implementation cannot recover
from an error.
So in this case, it doesn't seem to be "processing aborted by the user"
as noted where RE was caught. When a DOM error happens, e.g. not
wellformed, if no errorHandler is registered, the process will abort
without an error. It's possible to handle the case without throw&catch
RE. Please investigate.
Thanks,
Joe
On 8/15/16, 11:09 AM, Joe Wang wrote:
Hi Aleksej,
I suggest we get rid of the static abort. If RuntimeException happens,
check where it happens. The first use case looks suspicious as it just
returns if it's an instance of RE. For the 2nd case in DOM error
report, let's throw a RuntimeException with the specified error
message if error happens, and there's no handler or the handler failed
to handle it. (would be better than an empty RE)
Best,
Joe
On 8/15/16, 10:38 AM, Aleks Efimov wrote:
Hi,
Please, help to review the fix for memory leak [1] in
com.sun.org.apache.xerces.internal.dom.DOMNormalizer that is caused
by usage of static final exceptions.
This problem was already fixed in Apache Xerces project [2] and I
would like to backport it to JDK9 Xerces implementation.
Webrev with the changes:
http://cr.openjdk.java.net/~aefimov/8146961/9/00
The Tomcat reproducer attached to the bug report fails without the
fix and passes with the fix.
The JPRT and JCK testing shows no jaxp tests failures with the
proposed fix.
With Best Regards,
Aleksej
[1] https://bugs.openjdk.java.net/browse/JDK-8146961
[2] https://issues.apache.org/jira/browse/XERCESJ-1667
