DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=27994>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27994 Fatal Error causes endless loop when Error Handler defined..... Summary: Fatal Error causes endless loop when Error Handler defined..... Product: XalanJ2 Version: CurrentCVS Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: org.apache.xpath AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] OK, I had an XPath Exception that caused a fatal error which then brought our server to our Knee's. In looking at the problem, I found some interesting comments in the code, see below. I was able to work around the problem by throwing a TransformerException in my fatalError handler but the results were interesting because it dosen't just fail, it loops on my exception for a number of times, <5, then fails. Note: this fails in version 2.5.1 and 2.6 of XalanJ Node the source is from 2.5.1 and has been truncated. Code XPathParser#consumeExpected(char expected) error(XPATHErrorResources.ER_EXPECTED_BUT_FOUND, // Patch for Christina's gripe. She wants her errorHandler to return from // this error and continue trying to parse, rather than throwing an exception. // Without the patch, that put us into an endless loop. throw new XPathProcessorException(CONTINUE_AFTER_FATAL_ERROR); Which falls back to initXPath and is caught at the bottom half of the code, the recursive call into initXPath cause the fun to start all over again. XPathParser#initXPath( Compiler compiler, String expression, PrefixResolver namespaceContext) // Patch for Christine's gripe. She wants her errorHandler to return from // a fatal error and continue trying to parse, rather than throwing an // exception. // Without the patch, that put us into an endless loop. // // %REVIEW% Is there a better way of doing this? // %REVIEW% Are there any other cases which need the safety net? // (and if so do we care right now, or should we rewrite the XPath // grammar engine and can fix it at that time?) try { } catch (org.apache.xpath.XPathProcessorException e) { if(CONTINUE_AFTER_FATAL_ERROR.equals(e.getMessage())) { // What I _want_ to do is null out this XPath. // I doubt this has the desired effect, but I'm not sure what else to do. // %REVIEW%!!! initXPath(compiler, "/..", namespaceContext); } else throw e; } }
