Re: Problems with missing properties accessExternalSchema accessExternalDTD in Xerces2
[email protected] Tue, 16 Jan 2024 13:31:05 +0100
| Newsgroups | gmane.text.xml.xerces-j.user |
|---|---|
| Message-ID | <[email protected]> |
--=_570b6ae2dcd3d7ee1700eec46e3a17fa Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi Stanimir, 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? 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; Regards, Martin Am 2024-01-16 11:57, schrieb Stanimir Stamenkov: > Tue, 16 Jan 2024, /Martin Wunderlich/: > >> So, it seems there are two possible solutions here: >> >> - Ignore that recommendation from JEP-403, keep the included JAXP >> implementation that comes with the JRE and hope for the best ... or > > As far as I get JEP-403 recommends one shouldn't refer to JDK-specific > implementation (com.sun.org.apache.xerces.* vs. JAXP API) classes in > code. One shouldn't be doing it anyway. You didn't answer my previous > question - is that the case for you? JEP-403 doesn't recommend against > using the JDK-bundled JAXP implementation in general (as default JAXP > provider in your runtime). > >> - Find some other parser implementation that does not rely on Xerces >> and that does implement JAXP 1.5+ (but I am not aware of one) >> >> Any other ideas anyone? > > Could you specify what's your use case: > > 1. A software developer having direct control over the application > implementation; > 2. A system administrator trying to configure existing application > runtime. > > In my previous reply I've suggested developers shouldn't rely on > "accessExternalDTD" alone, for example. > > For the latter case I've suggested removing Xerces (the Apache library, > its JARs) from the runtime configuration/packaging, and relying on the > JDK-bundled implementation. This way one may rely on global > "accessExternalDTD" setting, though there's a minimal chance it may > break legitimate application functionality. --=_570b6ae2dcd3d7ee1700eec46e3a17fa 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>my use case is this: "A software developer having direct control over th= e application implementation"</p> <p>I might be misunderstanding the recommendation from JEP-403 then. In whi= ch way is "<span style=3D"color: #000000; font-family: 'DejaVu Sans', 'Bits= tream Vera Sans', 'Luxi Sans', Verdana, Arial, Helvetica;">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 J= DK is using Xerces under the hood as its JAXP implementation? </span><= /p> <p><span style=3D"color: #000000; font-family: 'DejaVu Sans', 'Bitstream Ve= ra Sans', 'Luxi Sans', Verdana, Arial, Helvetica;">In the code we're import= ing the following: </span></p> <div style=3D"color: #a9b7c6; background-color: #2b2b2b;"> <div style=3D"background-color: #2b2b2b;"> <pre style=3D"font-size: 10,5pt; font-family: 'JetBrains Mono',monospace;">= <span style=3D"color: #cc7832;">import </span>javax.xml.XMLConstants<span s= tyle=3D"color: #cc7832;">;<br /></span><span style=3D"color: #cc7832;">impo= rt </span>javax.xml.parsers.ParserConfigurationException<span style=3D"colo= r: #cc7832;">;<br /></span><span style=3D"color: #cc7832;">import </span>ja= vax.xml.parsers.SAXParser<span style=3D"color: #cc7832;">;<br /></span><spa= n style=3D"color: #cc7832;">import </span>javax.xml.parsers.SAXParserFactor= y<span style=3D"color: #cc7832;">;</span></pre> </div> </div> <p><span style=3D"color: #000000; font-family: 'DejaVu Sans', 'Bitstream Ve= ra Sans', 'Luxi Sans', Verdana, Arial, Helvetica;">Regards, </span></p> <p><span style=3D"color: #000000; font-family: 'DejaVu Sans', 'Bitstream Ve= ra Sans', 'Luxi Sans', Verdana, Arial, Helvetica;">Martin </span></p> <div id=3D"signature"></div> <p><br /></p> <p id=3D"reply-intro">Am 2024-01-16 11:57, 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">So, it seems there are two possible solutions here:<br= /><br />- Ignore that recommendation from JEP-403, keep the included JAXP = implementation that comes with the JRE and hope for the best ... or</blockq= uote> <br />As far as I get JEP-403 recommends one shouldn't refer to JDK-specifi= c implementation (com.sun.org.apache.xerces.* vs. JAXP API) classes in code= =2E One shouldn't be doing it anyway. You didn't answer my prev= ious question – is that the case for you? JEP-403 doesn't recom= mend against using the JDK-bundled JAXP implementation in general (as defau= lt JAXP provider in your runtime).</div> <div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">= </div> <div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace"> <blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2= px solid; margin: 0">- Find some other parser implementation that does not = rely on Xerces and that does implement JAXP 1.5+ (but I am not aware of one= )<br /><br />Any other ideas anyone?</blockquote> <br />Could you specify what's your use case:<br /><br />1. A software deve= loper having direct control over the application implementation;<br />2. A = system administrator trying to configure existing application runtime.<br /= ><br />In my previous reply I've suggested developers shouldn't rely on "ac= cessExternalDTD" alone, for example.<br /><br />For the latter case I've su= ggested removing Xerces (the Apache library, its JARs) from the runtime con= figuration/packaging, and relying on the JDK-bundled implementation. = This way one may rely on global "accessExternalDTD" setting, though there's= a minimal chance it may break legitimate application functionality.</div> </blockquote> </body></html> --=_570b6ae2dcd3d7ee1700eec46e3a17fa--