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 Sun, 07 Jul 2013 00:22:07 GMT

--- Comment #10 from Jeremy Boynes <> ---
Created attachment 30556
Start to refactor SchemaResolver not to key only on basename

I started on the patch I mentioned above. This changes SchemaResolver to use
the full systemId when resolving rather than just matching on the file name.
This led to discovery of 55204 which previously worked because an incorrect
path was being ignored.

As part of this I also made SchemaResolver a SAX2 EntityResolver2 so that is it
potentially more useful.

The previous implementation also had a dependency on a Digester in order to set
the publicId. This is not normally an EntityResolver's responsibility. I
removed this call and updated Digester to use the publicId reported by a
LexicalHandler, and did the same for the Digester's internal EntityResolver
implementation. This also allows SchemaResolver to be a singleton.

Verified with test-bio (I'm assuming these changes are independent of

I'm attaching this checkpoint as there are a few more changes I would like to
make which would be broader reaching. I noticed that the entries in Constants
do not reflect the distinction between public and system ids. For example,
WebDtdPublicId_23 is a public id for the 2.3 DTD but WebSchemaPublicId_24 is a
truncated version of the 2.4 system id. In the spirit of my previous comment
I'm going to propose a patch to clean up that naming, make the constant values
the fully qualified URIs (I'm going to assume for this that the values in
o.a.c.startup.Constants are for internal use only and can be changed), and
assume that the relative URIs can be made to work by moving the XSDs from jsp
to servlet. This will also allow a bit of cleanup in WebXml as setPublicId()
would only need to handle DOCTYPE-based versions and setVersion() only the
XSD-based versions. Finally, as Digester is already SAX2 aware, I will update
it to extend DefaultHandler2 and the corresponding EntityResolver2 and
LexicalHandler methods.

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