-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. 2. The namespace is not available to the EntityResolver. >>> 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. Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS4in3AAoJEBDAHFovYFnnCX0QAOnm6Ubdt3rqdt2LL9sf7oCM YJqHpHD732iHexKWxLg8oKZfNEup7oYXDGOmtNtNSI/Ulk9kzWsLrRvxCA4X+Jfw de13jdn1nE+5J+twx6j/29cM9PdW2R24zNBZowM0Rf3+Enlr8x5G1sgOA3Xh5Yh4 +yU4tWhX924lgM4bk7+fN8cNqdw9c48QWstH+1SkUzFmvIxl088Fo3foHEaG/YH+ 3vDL6116if0yg/k3uMHBVrytZ6fXudf3EO/GcrBZl6m8FyMfekZ4Y/DLktRPuDdu RadZoFdXU1HRV9gtn4GqlV/ozNU9DBcP45jra1rW4/i/1qCY9/TrY8dkKySG/toq 8UPabQxM+06wkkoGcmaR3xFgJw1cJ/cTiINjecSrTX+5jco2dKAdr4vN7ZCz9Lfe 1yqXpPBRf2yE/ZWf9o+UV5QpbUugetgAe/rhpRSZiJR7AvJTKagXI4R6SUo8xwZT yjYg9AW3EkMAtZHun4W1eKtlqGf3OBxZJY/EeQvtODinBC7KRRvRMsGxdleSYp1o xTtRBOwlp1hzajSzZZnh51ZyzKBu1fU9fDwIfitwTO5AznUBLAqA1gLnz35EE2+l ETv62Y+I+CDRNFezQ/IoFWbh/eDkShya69mLSXTG+gmm9kH0VbLJCMKXz/uhyOaN 7yQVo+5zAT1wz6CzHxXd =D6nW -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
