Re: Need a helpful Xalan-guy for xml-security

[maillist]

Hi,

I tested it and the following would be good:

class org.apache.xpath.CachedXPathAPI {
   public CachedXPathAPI(CachedXPathAPI previouslyCachedXPathAPI) {
      this.xpathSupport = previouslyCachedXPathAPI.xpathSupport;
   }

   public XPathContext getXPathContext() {
      return this.xpathSupport;
   }
}

class org.apache.xpath.XPathContext {
   protected DTMManager m_dtmManager = ...
}

I do not need the CachedXPathAPI(XPathContext) but I need the 
CachedXPathAPI.getXPathContext() method and access to a protected 
XPathContext.m_dtmManager because I extend XPathContext and need my own 
access to the DTMManager.

With these 3 changes, I can live very good ;-)

Thanks,
Christian

--On Dienstag, 11. Dezember 2001 10:31 -0500 [EMAIL PROTECTED] 
wrote:

>
>    public CachedXPathAPI() {
>       this.xpathSupport = new XPathContext();
>    }
>
>    public CachedXPathAPI(XPathContext xpathContext) {
>       this.xpathSupport = xpathContext;
>    }
>
>    public XPathContext getXPathContext() {
>       return this.xpathSupport;
>    }
>
> OK, that looks considerably better architecturally than exposing the guts
> of the XPathContext itself. I think we can live with that one, though I'd
> still rather replace the latter two with something like:
>    public CachedXPathAPI(CachedXPathAPI outerXPath) {
>       this.xpathSupport = outerXPath.xpathSupport;
>    }
> for reasons of encapsulation. Would that serve, or do you really need the
> lower-level operation? Or should I add both?
>
> Sanity check: When you share the XPathContext, you do share the previously
> established state. That's fine for sequential use, but may or may not be
> what you have in mind if you're going to recurse. Do we also need a copy
> constructor on XPathContext which shares the DTMManager but not the
> XPathContext's own stack, and a way to use that here? (That might be an
> argument for the low-level calls.)
>