Piotr Karwasz created XALANJ-2849:
-------------------------------------
Summary: getAssociatedStylesheet ignores supplied XMLReader
Key: XALANJ-2849
URL: https://issues.apache.org/jira/browse/XALANJ-2849
Project: XalanJ2
Issue Type: Bug
Security Level: No security risk; visible to anyone (Ordinary problems in
Xalan projects. Anybody can view the issue.)
Reporter: Piotr Karwasz
{{TransformerFactory.getAssociatedStylesheet}} ignores the {{XMLReader}}
carried by a {{SAXSource}} and always creates its own parser, unlike the JDK's
XSLTC fork, which honors it.
h2. Affected code
{{org.apache.xalan.processor.TransformerFactoryImpl.getAssociatedStylesheet(Source,
String, String, String)}} (Xalan-J 2.7.3).
For a non-{{DOMSource}} argument the method takes only the {{InputSource}}:
{code:java}
isource = SAXSource.sourceToInputSource(source);
baseID = isource.getSystemId();
{code}
and then unconditionally builds a fresh reader to scan for the
{{xml-stylesheet}} processing instructions:
{code:java}
javax.xml.parsers.SAXParserFactory factory =
javax.xml.parsers.SAXParserFactory.newInstance();
...
reader = jaxpParser.getXMLReader();
...
if (null == reader) {
reader = XMLReaderFactory.createXMLReader();
}
...
reader.setContentHandler(handler);
reader.parse(isource);
{code}
When the caller passes a {{SAXSource}} carrying its own configured
{{XMLReader}}, that reader is never consulted: only its {{InputSource}} is
used, and the PI scan runs on the newly created, differently configured parser.
h2. Expected behavior
When the argument is a {{SAXSource}} that carries an {{XMLReader}}, that reader
should be used for the PI scan, and a new one created only when the source
supplies none. This is exactly what the JDK's XSLTC fork
({{com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl}})
already does:
{code:java}
if (source instanceof SAXSource) {
reader = ((SAXSource)source).getXMLReader();
}
isource = SAXSource.sourceToInputSource(source);
...
if (reader == null) {
reader = JdkXmlUtils.getXMLReader(...);
}
{code}
h2. Why it matters
A caller who deliberately configures the reader in the {{SAXSource}} (namespace
handling, an {{EntityResolver}}, disabled external entity or DTD resolution)
reasonably expects that reader to parse the source. Because
{{getAssociatedStylesheet}} silently substitutes its own, those settings do not
apply to the PI scan: the substitute reader parses the stylesheet's external
DTD subset and external parameter entities at its own defaults, even when the
caller supplied a hardened reader precisely to prevent that. Aligning with the
JDK behavior closes the gap and makes {{SAXSource}} handling consistent across
the two {{getAssociatedStylesheet}} entry points.
h2. Suggested fix
Before creating a reader, honor a {{SAXSource}}-supplied one:
{code:java}
if (source instanceof SAXSource) {
reader = ((SAXSource) source).getXMLReader();
}
{code}
and create a new reader only when {{reader == null}}, mirroring the XSLTC fork.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
