[ http://issues.apache.org/jira/browse/XALANJ-1841?page=all ]
Brian Minchau updated XALANJ-1841:
----------------------------------
Version: 2.5
2.6
(was: Latest Development Code)
> Fatal Error causes endless loop when Error Handler defined.....
> ---------------------------------------------------------------
>
> Key: XALANJ-1841
> URL: http://issues.apache.org/jira/browse/XALANJ-1841
> Project: XalanJ2
> Type: Bug
> Components: XPath
> Versions: 2.5, 2.6
> Environment: Operating System: Other
> Platform: Other
> Reporter: John Gentilin
> Assignee: Xalan Developers Mailing List
> Attachments: qry_generic.xml, tc_bugs.xsl
>
> 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;
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
