You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by "Simon Kitching (JIRA)" <xa...@xml.apache.org> on 2004/11/18 04:17:24 UTC

[jira] Created: (XALANJ-1995) CachedXPathAPI doesn't cache under some cases

CachedXPathAPI doesn't cache under some cases
---------------------------------------------

         Key: XALANJ-1995
         URL: http://nagoya.apache.org/jira/browse/XALANJ-1995
     Project: XalanJ2
        Type: Improvement
  Components: XPath  
    Versions: 2.6    
 Environment: any
    Reporter: Simon Kitching
    Priority: Minor


I recently needed to optimise XPath operations in my application, and so
looked into the CachedXPathAPI class.

I found what appears to be a bug; the eval method which takes a
PrefixResolver parameter creates its own local xpathsupport object,
thereby completely bypassing the 'caching' that is supposed to be the
whole point of this class. The code works, but is no faster than the
(non-caching) XPathAPI implementation.

I also found found some duplicated code; one eval function can more
tidily be written by invoking another than by duplicating the
implementation.

And as a user of the CachedXPathAPI class, I found the javadoc comments
rather confusing; they explained the class in terms of the functionality
of lower-level classes which means the comments are not helpful unless
the reader already knows what those lower-level classes do. While I was
working on the class javadoc, I also did some very minor tweaking of the
javadoc on various methods.

Attached is a proposed patch that addresses these issues. I have run the
smoketest on this. Several smoketest tests fail, but they also fail when
running the plain CVS code without my patch. However I diffed the output
of smoketest before and after my patch and found no significant
differences.

Just to avoid confusion, the critical change is the removal of this line
from the eval(Node, String, PrefixResolver) method:
   XPathContext xpathSupport = new XPathContext();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org

[jira] Updated: (XALANJ-1995) CachedXPathAPI doesn't cache under some cases

Posted by "Simon Kitching (JIRA)" <xa...@xml.apache.org>.
     [ http://nagoya.apache.org/jira/browse/XALANJ-1995?page=history ]

Simon Kitching updated XALANJ-1995:
-----------------------------------

    Attachment: CachedXPathAPI.diff

> CachedXPathAPI doesn't cache under some cases
> ---------------------------------------------
>
>          Key: XALANJ-1995
>          URL: http://nagoya.apache.org/jira/browse/XALANJ-1995
>      Project: XalanJ2
>         Type: Improvement
>   Components: XPath
>     Versions: 2.6
>  Environment: any
>     Reporter: Simon Kitching
>     Priority: Minor
>  Attachments: CachedXPathAPI.diff
>
> I recently needed to optimise XPath operations in my application, and so
> looked into the CachedXPathAPI class.
> I found what appears to be a bug; the eval method which takes a
> PrefixResolver parameter creates its own local xpathsupport object,
> thereby completely bypassing the 'caching' that is supposed to be the
> whole point of this class. The code works, but is no faster than the
> (non-caching) XPathAPI implementation.
> I also found found some duplicated code; one eval function can more
> tidily be written by invoking another than by duplicating the
> implementation.
> And as a user of the CachedXPathAPI class, I found the javadoc comments
> rather confusing; they explained the class in terms of the functionality
> of lower-level classes which means the comments are not helpful unless
> the reader already knows what those lower-level classes do. While I was
> working on the class javadoc, I also did some very minor tweaking of the
> javadoc on various methods.
> Attached is a proposed patch that addresses these issues. I have run the
> smoketest on this. Several smoketest tests fail, but they also fail when
> running the plain CVS code without my patch. However I diffed the output
> of smoketest before and after my patch and found no significant
> differences.
> Just to avoid confusion, the critical change is the removal of this line
> from the eval(Node, String, PrefixResolver) method:
>    XPathContext xpathSupport = new XPathContext();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org