[Bug 55166] schemaLocation references between servlet and jsp XSDs are invalid
https://issues.apache.org/bugzilla/show_bug.cgi?id=55166 --- Comment #16 from Jackie Rosen jackie.ro...@hushmail.com --- *** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla. -- 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
[Bug 55166] schemaLocation references between servlet and jsp XSDs are invalid
https://issues.apache.org/bugzilla/show_bug.cgi?id=55166 --- Comment #15 from Konstantin Kolinko knst.koli...@gmail.com --- This eventually have been fixed in Tomcat 6 (r1561625) and Tomcat 7 (r1562103) and will be in 6.0.39, 7.0.51. -- 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
[Bug 55166] schemaLocation references between servlet and jsp XSDs are invalid
https://issues.apache.org/bugzilla/show_bug.cgi?id=55166 Mark Thomas ma...@apache.org changed: What|Removed |Added CC||david_s...@hotmail.com --- Comment #14 from Mark Thomas ma...@apache.org --- *** Bug 55313 has been marked as a duplicate of this bug. *** -- 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
[Bug 55166] schemaLocation references between servlet and jsp XSDs are invalid
https://issues.apache.org/bugzilla/show_bug.cgi?id=55166 --- Comment #12 from Mark Thomas ma...@apache.org --- I've been looking at the first issues raised - namely where the Servlet and JSP schemas are located. Currently, the schemas are split between [1] and [2]. This split creates the a problem that can easily been seen when viewing the schemas in Eclipse. A number of these schemas include entries along the lines of: xsd:include schemaLocation=xxx.xsd/ I've had a look at the W3C specs and there is a requirement that these locations are relative so that means the included files all need to be in the same location. With the files split between [1] and [2] there are numerous references that can't be resolved. I see two approaches to solving this: a) Move files from [2] to [1] b) Duplicate files between [1] and [2] Option a) Pros: Only a single copy of the files will exist Cons: The taglib files are not required by the Servlet API (the JSP ones are) Option b) Pros: servlet-api JAR won't contain unnecessary tablib files Cons: Duplication of a most of the files between the JARs On balance I think I prefer option a). I'd rather have 4 files in the servlet-api JAR that are only required when processing JSPs than duplicate nearly all of the files in the jsp-api JAR especially given that the jsp-api.jar depends on the servlet-api.jar anyway. In Tomcat 7 folks might be using these JARs from there current locations so I intend to fix this using option a) for Tomcat 8 only. The issue with the schema resolver belong in a new Bugzilla issue (or possibly issues - I haven't looked too hard at whether there is a single issue there or multiple issues). [1] http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/resources/ [2] http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/jsp/resources/ -- 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
[Bug 55166] schemaLocation references between servlet and jsp XSDs are invalid
https://issues.apache.org/bugzilla/show_bug.cgi?id=55166 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Mark Thomas ma...@apache.org --- The originally reported issue has been fixed in trunk for 8.0.x. Please open a new Bugzilla issue for any additional issues (one Bugzilla issues for each additional issue) you identified while working on this issue. -- 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
[Bug 55166] schemaLocation references between servlet and jsp XSDs are invalid
https://issues.apache.org/bugzilla/show_bug.cgi?id=55166 --- Comment #11 from Jeremy Boynes jboy...@apache.org --- Created attachment 30567 -- https://issues.apache.org/bugzilla/attachment.cgi?id=30567action=edit Updated patch This version assumes that the JSP XSDs can be moved to the same location as the Servlet XSDs they have relative references too. Updated the resolver to only require the systemIds specified in the spec docs. These are used to resolve the initial schema and from there all relative references are resolved as relative URIs. Moved the XML identifiers from o.a.c.startup to o.a.tomcat to be part of the API allowing them to be used from Jasper (which already depends on tomcat-api). Moved the resolver to o.a.t.u.res so that it too could be shared (there may be a better package for this but it seemed resource related). Updated Digester to extend DefaultHandler2 with its built in implementations of EntityResolver2 and Lexical handler. On WebXml, setPublicId() is now used only for files with a DOCTYPE (2.2 and 2.3) whereas setVersion() is used for all files using XmlSchema (2.4 and later) which means it can be simplified a little. Added test/webapp-2.2 to confirm 2.2 version was still correctly detected and added it to the other test cases using webapp-*. This change is now starting to collide with my patch for 53737 and I'll ping the dev list about how that could be combined. -- 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
[Bug 55166] schemaLocation references between servlet and jsp XSDs are invalid
https://issues.apache.org/bugzilla/show_bug.cgi?id=55166 Jeremy Boynes jboy...@apache.org changed: What|Removed |Added Status|NEEDINFO|NEW -- 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
[Bug 55166] schemaLocation references between servlet and jsp XSDs are invalid
https://issues.apache.org/bugzilla/show_bug.cgi?id=55166 Jeremy Boynes jboy...@apache.org changed: What|Removed |Added Component|Specification APIs |Catalina Severity|normal |enhancement -- 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
[Bug 55166] schemaLocation references between servlet and jsp XSDs are invalid
https://issues.apache.org/bugzilla/show_bug.cgi?id=55166 --- Comment #10 from Jeremy Boynes jboy...@apache.org --- Created attachment 30556 -- https://issues.apache.org/bugzilla/attachment.cgi?id=30556action=edit 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 connector). 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55166] schemaLocation references between servlet and jsp XSDs are invalid
https://issues.apache.org/bugzilla/show_bug.cgi?id=55166 --- Comment #8 from Konstantin Kolinko knst.koli...@gmail.com --- You are doing it wrong. a) You have to configure a resolver to be able to locate schemas. Tomcat uses org.apache.catalina.util.SchemaResolver as configured by org.apache.catalina.startup.DigesterFactory. See DigesterFactory#registerLocalSchema(). 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. c) You can bundle and redistribute schema files on your own, without relying on ones used internally by Tomcat. -- 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
[Bug 55166] schemaLocation references between servlet and jsp XSDs are invalid
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
[Bug 55166] schemaLocation references between servlet and jsp XSDs are invalid
https://issues.apache.org/bugzilla/show_bug.cgi?id=55166 --- Comment #4 from Mark Thomas ma...@apache.org --- Do you still see the issue if both the servlet-api.jar and jsp-api.jar are available on the class path? I'd expect the answer to be no since the TCK tests run with validation enabled for the XML parser and there are no issues resolving the various schemas. -- 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
[Bug 55166] schemaLocation references between servlet and jsp XSDs are invalid
https://issues.apache.org/bugzilla/show_bug.cgi?id=55166 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|REOPENED|NEEDINFO -- 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
[Bug 55166] schemaLocation references between servlet and jsp XSDs are invalid
https://issues.apache.org/bugzilla/show_bug.cgi?id=55166
--- Comment #5 from Jeremy Boynes jboy...@apache.org ---
Created attachment 30526
-- https://issues.apache.org/bugzilla/attachment.cgi?id=30526action=edit
full output from test run
I was seeing the problem with xjc running against the resources directory. That
may not be a typical manifestation.
However, I put together this testcase for validation
@Test
public void testValidation() throws Exception {
System.out.println(ServletContext = +
getClass().getResource(/javax/servlet/ServletContext.class));
System.out.println(JspFactory = +
getClass().getResource(/javax/servlet/jsp/JspFactory.class));
SchemaFactory schemaFactory =
SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
schemaFactory.setErrorHandler(new ErrorHandler() {
@Override
public void warning(SAXParseException exception) throws
SAXException {
exception.printStackTrace();
}
@Override
public void error(SAXParseException exception) throws SAXException
{
exception.printStackTrace();
}
@Override
public void fatalError(SAXParseException exception) throws
SAXException {
exception.printStackTrace();
}
});
URL url =
ServletContext.class.getResource(/javax/servlet/resources/web-app_3_0.xsd);
System.out.println(url = + url);
Schema schema = schemaFactory.newSchema(url);
}
which fails with
org.xml.sax.SAXParseException; systemId:
jar:file:/Users/jeremy/apache/apache-tomcat-7.0.41/lib/servlet-api.jar!/javax/servlet/resources/web-common_3_0.xsd;
lineNumber: 119; columnNumber: 46; schema_reference.4: Failed to read schema
document 'jsp_2_2.xsd', because 1) could not find the document; 2) the document
could not be read; 3) the root element of the document is not xsd:schema.
Caused by: java.io.FileNotFoundException: JAR entry
javax/servlet/resources/jsp_2_2.xsd not found in
/Users/jeremy/apache/apache-tomcat-7.0.41/lib/servlet-api.jar
The full output is attached. As you can see, it is looking for jsp_2_2.xsd in
same location as the web-common_3_0.xsd resource that is including it. I ran
against the lib directory from a download of 7.0.41.
I don't know how the TCK is validating. It may have a custom resolver for its
own copies of the XSDs.
--
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
[Bug 55166] schemaLocation references between servlet and jsp XSDs are invalid
https://issues.apache.org/bugzilla/show_bug.cgi?id=55166 Jeremy Boynes jboy...@apache.org changed: What|Removed |Added Attachment #30508|0 |1 is obsolete|| --- Comment #6 from Jeremy Boynes jboy...@apache.org --- Created attachment 30527 -- https://issues.apache.org/bugzilla/attachment.cgi?id=30527action=edit Patch to add testcase to trunk Patch to add the prior testcase to trunk. It passes if I svn copy the jsp xsds to javax/servlet/resources but I didn't do that in the patch in order to keep file history. It fails to validate on test/webapp/WEB-INF/web.xml so I also includes changes to make that file conform to the XSD (basically reordering a couple of elements). -- 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
[Bug 55166] schemaLocation references between servlet and jsp XSDs are invalid
https://issues.apache.org/bugzilla/show_bug.cgi?id=55166 Jeremy Boynes jboy...@apache.org changed: What|Removed |Added Attachment #30527|0 |1 is obsolete|| --- Comment #7 from Jeremy Boynes jboy...@apache.org --- Created attachment 30528 -- https://issues.apache.org/bugzilla/attachment.cgi?id=30528action=edit Same as 30527 but with ASF header and link to this issue -- 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
[Bug 55166] schemaLocation references between servlet and jsp XSDs are invalid
https://issues.apache.org/bugzilla/show_bug.cgi?id=55166 Jeremy Boynes jboy...@apache.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- Summary|Resources do not include|schemaLocation references |JSP xsds that are |between servlet and jsp |referenced from |XSDs are invalid |web-app/web-common | --- Comment #3 from Jeremy Boynes jboy...@apache.org --- (In reply to Konstantin Kolinko from comment #2) You'll find them in jsp-api.jar I missed that they were there, sorry for that. What is your issue? I ran into a problem trying to use xjc because web-common_3_1.xsd contains xsd:include schemaLocation=jsp_2_3.xsd/ and which did not resolve. The same applies to jsp_2_3.xsd when it is in the jsp jar because it in turn contains xsd:include schemaLocation=javaee_7.xsd/ which is back in the servlet jar. I updated the issue summary to reflect this. -- 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
