DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=28696>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28696 Jsp:root has invalid attribute: xsi:schemaLocation Summary: Jsp:root has invalid attribute: xsi:schemaLocation Product: Tomcat 5 Version: 5.0.19 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] It seems that Jasper is a bit strict about attributes on an XML JSP root element. Example JSP (same JSP causing stack trace listed below): <?xml version="1.0" encoding="UTF-8"?> <!-- $Id$ --> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"; version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/JSP/Page http://java.sun.com/dtd/jspxml.xsd";> </jsp:root> These attributes seem to be perfectly valid, page 3-17 of the JSP 2.0 specification (also in http://java.sun.com/dtd/jspxml.xsd) has this annotation about the root element: <xsd:element name = "root"> <xsd:annotation> <xsd:documentation> The root element of all JSP documents is named root. Authors may, if they wish, include schema location information. If specified, the information may appear as attributes of the root element as follows: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/JSP/Page xsd-file-location" Documents should not specify the system identifier of a DTD in a DOCTYPE declaration. </xsd:documentation> </xsd:annotation> ... The reason I am using (or trying to use) XMLSchema-instance is that it seems to be the only way to trigger Ant's xmlvalidate task to perform XML Schema validation (perhaps the only way to trigger Xerces to perform Schema validation, not just xmlvalidate). It's probably absurd for me to think that my build scripts will be able to validate real-world JSPs, but I'm one of those pedantic sorts of people, I dream of the day that an IDE (emacs!) can resolve all XML namespaces into schemas, possibly JSP tag libraries into schema-like metadata (perhaps a plug-in for Xerces) and hack away happily without having 5 browser tabs and 2 PDFs open jumping back and forth. Full stack trace: 2004-04-29 13:34:36 StandardWrapperValve[jsp]: Servlet.service() for servlet jsp threw exception org.apache.jasper.JasperException: /index.jspx(6,96) Jsp:root has invalid attribute: xsi:schemaLocation at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:83) at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:402) at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:236) at org.apache.jasper.compiler.JspUtil.checkAttributes(JspUtil.java:348) at org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:432) at org.apache.jasper.compiler.Node$JspRoot.accept(Node.java:554) at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2180) at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2230) at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2236) at org.apache.jasper.compiler.Node$Root.accept(Node.java:485) at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2180) at org.apache.jasper.compiler.Validator.validate(Validator.java:1518) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:247) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:456) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:553) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:291) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:257) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:184) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:578) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:206) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:833) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:732) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:619) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:688) at java.lang.Thread.run(Thread.java:534) In case your're curious (or someone at Sun is looking), Sun has bugs with their JSP XML Schema, first off the one they've copied into the JSP 2.0 spec is really the 1.2 XSD. They don't seem to have a JSP 2.0 XSD anywhere. The 1.2 XSD is locked into version="1.2" (very easy to change when using a Catalog and a local copy of the XSD). Finally a regular expression in the XSD is broken (also easy to fix as Xerces reports it in plain english!). Here's the output of xmlvalidate: [xmlvalidate] /dtd/jspxml.xsd:238:42: InvalidRegex: Pattern value '[A-Za-z0-9_-]*/[A-Za-z0-9_-]*(;\s*(charset=)?[A-Za-z0-9_-]*)?' is not a valid regular expression. The reported error was: ''-' is an invalid character range. Write '\-'.'. [xmlvalidate] /dtd/jspxml.xsd:249:42: InvalidRegex: Pattern value '[A-Za-z0-9_-]*/[A-Za-z0-9_-]*' is not a valid regular expression. The reported error was: ''-' is an invalid character range. Write '\-'.'. [xmlvalidate] /home/gturner/src/newedgenetworks/zhenghesrc/server/src/web/index.jspx:6:96: cvc-complex-type.3.1: Value '2.0' of attribute 'version' of element 'jsp:root' is not valid with respect to the corresponding attribute use. Attribute 'version' has a fixed value of '1.2'. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
