"Christopher Schultz" <ch...@christopherschultz.net> wrote in message
news:4ae758a0.5050...@christopherschultz.net...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Bill,
>
> On 10/26/2009 9:44 PM, Bill Barker wrote:
>> "Christopher Schultz" <ch...@christopherschultz.net> wrote in message
>>> On the other hand, shouldn't the JSP compiler pass-through everything
>>> except for directives? HTML is a common enough use case for JSP that
>>> SGML comments ought to be tolerated in these cases.
>>
>> Except for the fact that section 5.4 of the (2.1) JSP spec precludes
>> having
>> anything except <jsp:param /> in the body of a <jsp:include> element.
>> Allowing template text in there is then a Container-specific feature and
>> so
>> renders the webapp non-portable.
>
> I read 5.4 and while the text doesn't say anything about this, the
> formal syntax of <jsp:include> does:
>
> "
> Syntax
> [...]
> <jsp:include page="urlSpec" flush="true|false">
> { <jsp:param .... /> }*
> </jsp:include>
> "
>
> There, no other content appears to be allowed. However, other sections
> of the JSP specification are less ambiguous. For instance, section 5.15
> (<jsp:text>) specifically says:
>
> "
> No subelements may appear within jsp:text; for example the following
> fragment is invalid and must generate a translation error.
> "
>
> The closest 5.4 comes is this:
>
> "
> A jsp:include action may have jsp:param subelements that can provide
> values for some parameters in the request to be used for the inclusion.
> "
>
> Back to section 5.15, this is an interesting tidbit:
>
> "
> When within a JSP document, of course, the body content needs to
> additionally conform to the constraints of being a well-formed XML
> document, so the following example, although valid in a JSP page is
> invalid in a JSP document:
> "
>
> The above is not qualified by anything mentioning the difference between
> .jsp and .jspx files or anything like that. I would expect that any
> SGML-style comments within a <jsp:text> element would, in fact, be
> ignored by the JSP processor when producing output since it presupposes
> XML semantics. Instead, the JSP compiler (in my 5.5.26 environment)
> produces an error for this document:
>
> <jsp:text>
> <!-- This is a SGML-style comment -->
> </jsp:text>
Within the spec, "JSP document" is the same as ".jspx", whereas "JSP page"
is the same as ".jsp".
I've confirmed that this example causes an exception in 6.0 (using latest
checkout from svn) when used in ".jsp" syntax (it works fine in ".jspx"
syntax, and just outputs a blank line). Since SGML comments are simply
template text in ".jsp" syntax, it looks like you have found a bug. This
would be especially true if:
<jsp:text>
This is some content ${foo.content < 3}
</jsp:text>
fails, but haven't tested it.
>
> The error is:
>
> Exception: org.apache.jasper.JasperException: /test.jsp(3,0) '&lt;',
> when appears in the body of &lt;jsp:text&gt;, must be
> encapsulated within a CDATA
> Stack Trace:
> org.apache.jasper.JasperException: /test.jsp(3,0) '&lt;',
> when appears in the body of &lt;jsp:text&gt;, must be
> encapsulated within a CDATA
> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
>
> This error seems consistent with the "no subelements" clause in S.5.15,
> but I see no such restriction placed on <jsp:include>.
>
>> It would be a bug if the error happened for a page in XML syntax however.
>
> I think the JSP specification has a little multiple-personality disorder
> when it comes to XML-looking-syntax versus actual XML syntax. It's
> unfortunate, since it can really confuse people.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkrnWJ8ACgkQ9CaO5/Lv0PBhkgCdHL88GleiLT4mo4wf2K3q9DTD
> zB8An1Lk12w/HqvPZYPxbWERfJSJauln
> =4VVb
> -----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
