-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 1/24/14, 3:53 AM, Mark Thomas wrote: > On 23/01/2014 15:25, Christopher Schultz wrote: >> On 1/23/14, 10:17 AM, Mark Thomas wrote: >>> On 23/01/2014 15:11, Christopher Schultz wrote: > >>>> If that's true, then the Digester should be using the public >>>> namespace id of the schema and ignoring the (incomplete) URL >>>> provided by the XML document in order to locate the Schema >>>> in the local catalog. (I inadvertently said "system id" in my >>>> previous message, but I meant public namespace id... that >>>> is, "http://java.sun.com/xml/ns/j2ee";). > > There are a couple of difficulties with that. > > 1. The namespace does not identify a single schema - it is > associated with several. *enormous eyeroll* I didn't realize that. I just looked at http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd and http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd and they both have this declaration: <xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"; targetNamespace="http://java.sun.com/xml/ns/j2ee"; xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"; There is no reason, however, that we couldn't merge the schemas together into a single file (or, probably more appropriately, load them all together from their separate files) and use the collection for validation regardless of the actual document type. > 2. The namespace is not available to the EntityResolver. I've gotten lost in the various resolver classes. Which one were you looking at? EntityResolver has public and system ids... not sure what those end up being when loading a Schema. I have sample code here which deals with DTDs and the various entities (e.g. system ids like "-//W3C//ENTITIES Latin 1 for XHTML//EN") but I don't appear to have anything set up for caching schemas. All of this /should/ be available from xml.apache.org/commons. I haven't looked at their code. >>>> Given the XML document in the original post, what is causing >>>> Tomcat /not/ to load that local XML Schema? > >>> The way the new custom resolver is written. As per my original >>> response, we could look at better handling for this case. I'd >>> need to go back to the archives and research if there is a >>> reason for the current behaviour. > >> Okay. Having written a few custom resolvers for just this >> purpose, I recall them being a total PITA to get right. > > The resolver only has the incomplete location > "web-jsptaglibrary_2_0.xsd" to work with. Such a location is > normally resolved as relative to the location of the document using > it. Since the document containing this reference is a TLD in a web > app, that isn't going to work unless the schemas are located > alongside the TLDs. > > Given that later versions of the standard tag libraries use an > absolute location of > "http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd"; (which > Tomcat recognises and directs the parser to its local copy) I'm > minded to view this as an implementation bug in that tag library > that can be worked around by disabling TLD validation. > > We could take the view that if we see a location of > "web-jsptaglibrary_2_0.xsd" (or any other schema name in the j2ee > namespace) we can assume it is a j2ee schema and resolve it as > such. As long as this is a fall-back position (i.e. the relative to > current resource location is checked first) then I don't think > there is any risk associated with it. What about simply providing all the components of the .../j2ee namespace and using them together? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS58mVAAoJEBzwKT+lPKRYbU0P/AtoejSyh0PPx0Eb59b7+IM4 PRng+iHNvJxV42/zmOR0l+AxBQjJceIkhi03mZu34WLqgy6juUWlzbqxdwsFIbTh MxdoesvYw1aTi3JtunKCvsbad/wMJisaKNzGeMoQ+qBCKRlJYKxt5D8aDIWJMB0/ XYosFZponO6bXWYJSwD0iX5YglFwjtDsQeOdGV7eCExRCnGoMaP43nQQNE5OsxZK WwIVKdRLIQu5OV/6PcWCeaJU/J5FcXsjZetSaImOyuEZKzZZb5cJ3XgGvCtIx7/X KiefJYjMI/yjbEr2FA0IMs6IV6d8vE00h39KQALejX0R9z+RJR3OvZxZU8VVWH0P Y9jd8l2v3mf0WB2cMHHW5o7l4Mg99+J5IQtTXIAbl5j8iQfVbSWRnHlyeL/2ec71 tzrVhSlGAbVebaQVRFTE+sgwoPhc4OVim1Uf9xmS7T/DZ61AIPdCEYyWmXSvnAOM BgWA/z05k3t5xq6S9fMZMchXocFZZKxwVXOK2wiqez6aF8rssMCITpicQy8Vl59v 46q8arJ8GLESyFAV9zrJ2JBH5RP1e3Ei8rSnBzemclrMzzrfqJBK1RFc3t/l6YUG HQSmDWj/hUCDcFqz1lVu5l7XuwDAeKWhdqDY9BQE2aPEVazqkg7NKFxg2ZL4d2Cg Ffo9Mggss3eQqCrcfw7t =wdgb -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
