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. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
