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. >
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). Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
