> XSLTProcessorEnvSupportDefault::parseXML() uses the current
> XMLParserLiaison instance, so as long as the EntityResolver instance
is
> installed into the instance, everything should work as planned.
Perhaps
> there's a bug?
Looking at the XSLTProcessorEnvSupportDefault::parseXML implementation,
here is the relevant bit:
if (m_processor == 0)
{
return m_defaultSupport.parseXML(urlString, base);
}
else
{
// builds an XSLTInputSource itself
...
}
So, if an XSLTProcessor is installed, it uses an XPathEnvSupportDefault
instance that you have no way to override. That doesn't seem like it
would help.
Also, I can't think of a way that one could construct an
XSLTProcessorEnvSupportDefault with an XSLTProcessor instance without
jumping through hoops. XSLTProcessorImpl requires an
XSLTProcessorEnvSupport object during construction. And processor can
only be set in XSLTProcessorEnvSupport during construction.
Cheers,
Brian
