2015-11-09 17:35 GMT+03:00 Konstantin Kolinko <knst.koli...@gmail.com>: > 2015-11-06 15:12 GMT+03:00 Mark Thomas <ma...@apache.org>: >> 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: >>>> https://java.net/jira/browse/JSP_SPEC_PUBLIC >>>> >>>> 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, https://bz.apache.org/bugzilla/show_bug.cgi?id=57136#c31 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 https://glassfish.java.net/download.html and download glassfish-4.1.1-web.zip 2. After unzipping GF, copy test.war into glassfish4/glassfish/domains/domain1/autodeploy/ 3. Start it cd glassfish4/bin asadmin start-domain 4. Open the page in browser http://localhost:8080/test/ Page with double escaped variant works. Page with no double escaping fails: org.apache.jasper.JasperException: /test1.jsp(27,66) PWC6031: Unterminated <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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
