tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 55166] schemaLocation references between servlet and jsp XSDs are invalid
Date Fri, 05 Jul 2013 20:21:52 GMT

--- Comment #9 from Jeremy Boynes <> ---
(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 =
  namespaceURI =
  publicId = null
  systemId = jsp_2_2.xsd
  baseURI =

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.
"" 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

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

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. for use in deployment
descriptors, or with other external schemas (e.g. 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:
For additional commands, e-mail:

View raw message