tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <>
Subject Re: On escaping of EL in attributes (BZ 57136)
Date Thu, 19 Nov 2015 10:18:36 GMT
2015-11-09 17:35 GMT+03:00 Konstantin Kolinko <>:
> 2015-11-06 15:12 GMT+03:00 Mark Thomas <>:
>> On 06/11/2015 11:47, Christopher Schultz wrote:
>>> On 11/5/15 4:34 AM, Mark Thomas wrote:
>>>> On 05/11/2015 08:48, Mark Thomas wrote:
> <...>
>>>> At this point, I don't see a clear argument one way or the other.
>>>> I've looked through the open JSP spec issues:
>>>> and I don't see anything for this. I do see a lot of very old issues
>>>> that don't appear to have been looked at for some time.
>>>> Given the lack of clarity of the which behaviour is correct, I think we
>>>> have little choice but to make this optional and that we should get this
>>>> done before the next 8.0.x release. I intend to start working on that in
>>>> trunk today.
> <...>
>> If we did have the TCK we could challenge it again (on the grounds the
>> spec was never updated so surely that must mean the spec is right and
>> the TCK is wrong)
>>> On the other hand, nobody ready the TCK... only the spec.
>> Indeed.
>>> So most users will expect form 2.
>> If they read the spec carefully enough (and to be fair it took me
>> several days of reading and re-reading the relevant bits to get to the
>> point I was happy that I understood what it meant) they should expect
>> form 1.
> If I were in the footwear of somebody who implements a web application
> that has to run on all web containers implementing the specification,
> my position will be:
> All I would care is that all web containers implement this part of
> specification in the same way. In this case I can "write once, run
> everywhere", which is usually expected of Java.
> If this is enforced not through the text of the document, but through
> the TCK, it is a pity (and a shame on spec leader), but it solves my
> problem.
> It is unlikely that some test were removed from TCK unless spec leader
> officially allows undefined behaviour across different
> implementations. As such, testing this example in an alternate
> implementation (e.g. RI) will make a guess on what behaviour is
> expected here.  (Maybe somebody on users list would like to do
> testing).
> That aside,
> as I mention in BZ 57136, form 2 (double escaping) provides better
> historical compatibility with pre-EL use of tag libraries (JSTL 1.0 /
> JSP 1.2 version of EL).
> form 1 (single escaping) is easier to read and write and provides
> uniformity across using EL in template text and EL in tags.
> Syntax hiliting in Eclipse IDE (4.4.2 Luna SR2) breaks at current
> /tomcat-7.0.x/test/webapp-3.0/el-method.jsp (form 1).  I have not yet
> upgraded to current Mars 4.5[.1] to test it there.

I attached sample web application to the issue,

Testing with Glassfish 4.1.1, it also expects double escaping.

I am not a user of Glassfish, so I do not know yet what configuration
options are there if this feature is configurable.

My steps:
1. Follow  and download
2. After unzipping GF, copy test.war into

3. Start it
cd glassfish4/bin
asadmin start-domain

4. Open the page in browser

Page with double escaped variant works.
Page with no double escaping fails:

org.apache.jasper.JasperException: /test1.jsp(27,66) PWC6031:
Unterminated &lt;c:if tag

(GRRR: It is not Apache Jasper. They were lazy to rename the package
and are abusing the trademarks...)

5. Stop it
cd glassfish4/bin
asadmin stop-domain


As such, I think the default value of "quoteAttributeEL" option in
Jasper shall be changed to "true". The same in JspC, where it would
need a "-no-quoteAttributeEL" command line option.

BTW, jasper-howto.xml already documents that the default is true,
which does not match the code.

Best regards,
Konstantin Kolinko

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message