https://issues.apache.org/bugzilla/show_bug.cgi?id=55166
--- Comment #9 from Jeremy Boynes <jboy...@apache.org> --- (In reply to Konstantin Kolinko from comment #8) > a) You have to configure a resolver to be able to locate schemas. > I should not need to use a resolver for this case. The base location of the schema file is known in the call to newSchema(url) and all the references from that file (its includes) are relative URIs. You can see that if you provide a LSResourceResolver to the schemaFactory where it gets called with type = http://www.w3.org/2001/XMLSchema namespaceURI = http://java.sun.com/xml/ns/javaee publicId = null systemId = jsp_2_2.xsd baseURI = jar:file:/Users/jeremy/apache/apache-tomcat-7.0.41/lib/servlet-api.jar!/javax/servlet/resources/web-common_3_0.xsd Resolving the relative URI of the systemId against the base gives an absolute local URI for the resource being included. This works fine for all the XSDs used by the Servlet specification (for example, the include from web-app to web-common) but fails for the JSPs XSD as it is not in the same relative location as the spec assumes. > Tomcat uses org.apache.catalina.util.SchemaResolver as configured by > org.apache.catalina.startup.DigesterFactory. > See DigesterFactory#registerLocalSchema(). In the Digester code registerLocalSchema(), the local resources are being registered with the filename as the publicId. I don't believe that is correct for the XmlSchema resources - the publicIds are there DTD-based resources with a <!DOCTYPE>. For XSD-based documents, xsi:schemaLocation is used to provide the *systemId* for the schema i.e. "http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"; and the resolver should be using that to map to the local cached copy. It works because SchemaResolver uses a single lookup table for both publicId and systemId and because (on line 112) it strips the systemId down to just the basename. This stripping down is not actually needed if you see what systemId the EntityResolver is being called with: http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd (returns jar:file:/Users/jeremy/apache/tomcat/trunk/output/build/lib/servlet-api.jar!/javax/servlet/resources/web-app_3_1.xsd) jar:file:/Users/jeremy/apache/tomcat/trunk/output/build/lib/servlet-api.jar!/javax/servlet/resources/web-common_3_1.xsd jar:file:/Users/jeremy/apache/tomcat/trunk/output/build/lib/servlet-api.jar!/javax/servlet/resources/javaee_7.xsd http://www.w3.org/2001/xml.xsd ... jar:file:/Users/jeremy/apache/tomcat/trunk/output/build/lib/servlet-api.jar!/javax/servlet/resources/jsp_2_3.xsd As you can see, the parser is resolving the <include schemaLocation> as a URI relative to the containing document resulting in a systemId for the "jsp_2_3.xsd" relative URI that is in the same place as the containing ".../web-common_3_1.xsd" document. SchemaResolver's implementation works by stripping that down to "jsp_2_3.xsd" and mapping that to the JSP jar. This works but would not be needed if the XSDs were in the same location relative to each other as they are at http://xmlns.jcp.org/xml/ns/javaee/ This could simplify the Digester as its SchemaResolver would only need to be configured with the systemIds that are documented by the specifications (e.g. http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd) for use in deployment descriptors, or with other external schemas (e.g. http://www.w3.org/2001/xml.xsd). It would not need to be configured with the internal references that are not defined by the specifications (e.g. web-common_3_1.xsd, jsp_2_3.xsd and so on). I'll put together a patch to see how much of a difference it makes. > > b) You can use SchemaFactory.newSchema(Source[]). I do not know whether it > helps in your case (maybe it does not help with includes), but it is a way > to pass several schema files to a SchemaFactory. It does not help with the includes as they are using the relative URI references between schema documents. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
