Re: Problems with missing properties accessExternalSchema accessExternalDTD in Xerces2
[email protected] Thu, 18 Jan 2024 09:21:22 +0100
| Newsgroups | gmane.text.xml.xerces-j.user |
|---|---|
| Message-ID | <[email protected]> |
--=_39c73c9b43ae9da66a4625631165c299
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Hi Stanimir,
Thank you so much for this very clear and elaborate explanation. It is
much clearer to me know that have in fact been reading the JEP-403
incorrectly, assuming it refers to any use of the JRE bundled Xerces
parser. So, as long as we stick to coding against the JAXP APIs only and
not use any Xerces API directly, we are good.
Thank you also for the hint on entity resolving! That's an interesting
approach which I hadn't considered.
Regards,
Martin
Am 2024-01-16 17:54, schrieb Stanimir Stamenkov:
> Tue, 16 Jan 2024, /Martin Wunderlich/:
>
>> my use case is this: "A software developer having direct control over
>> the application implementation"
>>
>> I might be misunderstanding the recommendation from JEP-403 then. In
>> which way is "the JDK's internal copy of the Xerces XML processor"
>> different from "JDK-bundled JAXP implementation"? I was assuming that
>> this is this the same thing, as the JDK is using Xerces under the hood
>> as its JAXP implementation?
>
> Yes, with "the JDK-bundled JAXP implementation" I'm referring to the
> "JDK's internal copy of the Xerces". Note, that implementation is
> different from Apache Xerces. It uses different packages at least -
> com.sun.org.apache.xerces.*
>
> Still, JEP-403 doesn't recommend against using it as a runtime JAXP
> provider - it recommends against referring the implementation classes
> directly in code, f.e.:
>
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl
>
> but using the implementation just via the JAXP APIs. It is all because
> this implementation detail is intended to be sealed by JPMS, and
> wouldn't be directly accessible by user code.
>
>> In the code we're importing the following:
>>
>> import javax.xml.XMLConstants;
>> import javax.xml.parsers.ParserConfigurationException;
>> import javax.xml.parsers.SAXParser;
>> import javax.xml.parsers.SAXParserFactory;
> So it seems you're using only JAXP APIs and should be all fine,
> regardless of which JAXP provider is plugged into the runtime.
>
> Here's more detailed example of what I've meant developers should
> always provide/configure to their parser instances:
>
> SAXParserFactory spf = SAXParserFactory.newInstance();
> SAXParser saxParser = spf.newSAXParser();
> XMLReader xmlReader = saxParser.getXMLReader();
> EntityResolver
> noExternalEntitiesResolver = (publicId, systemId) -> {
> return new InputSource(new StringReader(""));
> };
> xmlReader.setEntityResolver(noExternalEntitiesResolver);
> ...
> xmlReader.parse(...);
>
> Using SAXParser directly would require you to implement
> `resolveEntity(String publicId, String systemId)` on your
> DefaultHandler (ContentHandler), instead.
>
> You may implement more sophisticated entity resolver which behavior may
> be configured via application-specific vs. general JAXP configuration,
> and could delegate to a CatalogResolver for required entities packaged
> as application resources, but note how the above example differs from
> "accessExternalDTD":
>
> saxParser.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "");
>
> The latter configuration prohibits any external entities and will fail
> the parse operation if an external reference is found, for example:
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
>
> The former example substitutes all external entities with empty content
> which would result in a successful non-validating (XML DTD) parsing for
> most XML documents. You could also have you entity resolver throw an
> exception, if any external entities are not expected and strictly
> prohibited by your application.
--=_39c73c9b43ae9da66a4625631165c299
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=
eva,sans-serif'>
<p>Hi Stanimir, </p>
<p>Thank you so much for this very clear and elaborate explanation. It is m=
uch clearer to me know that have in fact been reading the JEP-403 incorrect=
ly, assuming it refers to any use of the JRE bundled Xerces parser. So, as =
long as we stick to coding against the JAXP APIs only and not use any Xerce=
s API directly, we are good. </p>
<p>Thank you also for the hint on entity resolving! That's an interesting a=
pproach which I hadn't considered. </p>
<p>Regards, </p>
<p>Martin </p>
<div id=3D"signature"></div>
<p><br /></p>
<p id=3D"reply-intro">Am 2024-01-16 17:54, schrieb Stanimir Stamenkov:</p>
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
Tue, 16 Jan 2024, /Martin Wunderlich/:<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">my use case is this: "A software developer having dire=
ct control over the application implementation"<br /><br />I might be misun=
derstanding the recommendation from JEP-403 then. In which way is "the JDK&=
rsquo;s internal copy of the Xerces XML processor" different from "JDK-bund=
led JAXP implementation"? I was assuming that this is this the same thing, =
as the JDK is using Xerces under the hood as its JAXP implementation?</bloc=
kquote>
<br />Yes, with "the JDK-bundled JAXP implementation" I'm referring to the =
"JDK's internal copy of the Xerces". Note, that implementation is dif=
ferent from Apache Xerces. It uses different packages at least &ndash=
; com.sun.org.apache.xerces.*<br /><br />Still, JEP-403 doesn't recommend a=
gainst using it as a runtime JAXP provider – it recommends against re=
ferring the implementation classes directly in code, f.e.:<br /><br /> =
; com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl<br /><br />b=
ut using the implementation just via the JAXP APIs. It is all because=
this implementation detail is intended to be sealed by JPMS, and wouldn't =
be directly accessible by user code.<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">In the code we're importing the following:<br /><br />=
import javax.xml.XMLConstants;<br />import javax.xml.parsers.ParserConfigur=
ationException;<br />import javax.xml.parsers.SAXParser;<br />import javax.=
xml.parsers.SAXParserFactory;</blockquote>
So it seems you're using only JAXP APIs and should be all fine, regardless =
of which JAXP provider is plugged into the runtime.<br /><br />Here's more =
detailed example of what I've meant developers should always provide/config=
ure to their parser instances:<br /><br /> SAXParserFactory sp=
f =3D SAXParserFactory.newInstance();<br /> SAXParser saxParse=
r =3D spf.newSAXParser();<br /> XMLReader xmlReader =3D saxPar=
ser.getXMLReader();<br /> EntityResolver<br /> &n=
bsp; noExternalEntitiesResolver =3D (publicId, systemI=
d) -> {<br /> return new InputSource(new Stri=
ngReader(""));<br /> };<br /> xmlReader.setEntity=
Resolver(noExternalEntitiesResolver);<br /> ...<br /> &n=
bsp; xmlReader.parse(...);<br /><br />Using SAXParser directly would requir=
e you to implement `resolveEntity(String publicId, String systemId)` on you=
r DefaultHandler (ContentHandler), instead.<br /><br />You may implement mo=
re sophisticated entity resolver which behavior may be configured via appli=
cation-specific vs. general JAXP configuration, and could delegate to a Cat=
alogResolver for required entities packaged as application resources, but n=
ote how the above example differs from "accessExternalDTD":<br /><br />&nbs=
p; saxParser.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "");<br /=
><br />The latter configuration prohibits any external entities and will fa=
il the parse operation if an external reference is found, for example:<br /=
><br /> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transi=
tional//EN"<br /><br />"<a href=3D"http://www.w3.org/TR/xhtml1/DTD/xhtml1-t=
ransitional.dtd" target=3D"_blank" rel=3D"noopener noreferrer">http://www.w=
3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd</a>"><br /><br />The former =
example substitutes all external entities with empty content which would re=
sult in a successful non-validating (XML DTD) parsing for most XML document=
s. You could also have you entity resolver throw an exception, if any=
external entities are not expected and strictly prohibited by your applica=
tion.</div>
</blockquote>
</body></html>
--=_39c73c9b43ae9da66a4625631165c299--