2014-01-24 Konstantin Kolinko <knst.koli...@gmail.com>: > 2014/1/24 Mark Thomas <ma...@apache.org>: >> 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. >>
We could add "web-jsptaglibrary_2_0.xsd" to our lookup table (like we do when calling DigesterFactory.addSelf()) > > Specification: > http://www.w3.org/TR/xmlschema-1/#xsi_schemaLocation > http://www.w3.org/TR/xmlschema-1/#schema-loc > > Personally, I feel safer to use our local copy of the schema over one > loaded from elsewhere. > I suspect that if needed our schemas can be overwritten by placing > unpacked resources into ${catalina.base}/lib. > > AFAIR from debugging, loading a schema for web.xml involves loading a > dozen of xsd resources. This loading is repeated for each > web-fragment.xml. I wonder whether such Schema objects could be > cached. > > (Given that such loading is performed internally by XML processor in > JRE, I do not see an easy way here. > A possible way is that it is possible to create a > javax.xml.validation.Schema explicitly and explicitly perform > Schema.newValidator().validate(...) on the document). > If it is possible to go to the route of cached javax.xml.validation.Schema, 1) We know what resource we are parsing (we know it is a TLD, it is a web.xml, etc.) 2) How to identify a schema, if several versions of it are available? I think that xsi:schemaLocation shall be ignored in this case. What is left are: - Namespace of the root element - version attribute. In some cases those are not in sync, usually using a newer namespace with older version but sometimes vise versa. An example: https://bugs.eclipse.org/bugs/show_bug.cgi?id=351040 (My copy of Eclipse is patched against bug 351040, so I did not notice its effect for 7.0.50). In some cases there is no schema, but a DTD. If we go the cached Schema route, I think it is possible to implement it by doing validation after parsing, or having some preliminary parsing step (looking only for namespace and version attribute) Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
