tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: EL processing enhancements for TC 7 (re: [Bug 43819] thread)
Date Mon, 04 Jan 2010 15:19:21 GMT
On 04/01/2010 15:01, Konstantin Kolinko wrote:
> Will you change the parsing, or it will affect validation only? I was
> not looking in the sources, so I have some difficulty to grasp what
> you are mentioning above.

The current parsing is going to have to change to handle the addition of
method invocation to the unifed EL.

> 1. There are certain differences in escaping rules between JSP pages,
> JSP documents and EL expressions.
> In the EL expressions themselves there are differences in escaping
> between Literal-expressions (EL.1.2.2) (the chapter numbers are from
> "Expression Language 2.2" spec) and Eval-expressions (EL.1.2.1).
> The escaping rules in EL.1.3 apply to the string literals in
> Eval-expressions, but not to Literal expressions.
> Specifically, the following test in is wrong:
>   assertEquals("\\", evaluateExpression("\\\\"));
> It should be
>   assertEquals("\\\\", evaluateExpression("\\\\"));
>   assertEquals("\\", evaluateExpression("${'\\\\'}"));
> See also
> and
> JSP.10.1.11 Request-Time Attribute Expressions

I agree with your analysis. I wasn't planning on addressing any of this
at this stage.

> 2. I am hesitant to try fixing the EL parser right now (at least until
> we release the next 6.0.x), because I suspect that it leverages
> certain Jasper behavior.

+1. Past experience is that the EL implementation is very fragile.

> 3. Testing compliance with the escaping rules should involve JSP pages
> and Jasper.

+1. In Tomcat 7 it is much easier to write test cases that use an
embedded Tomcat instance for things like this. I have some test JSPs
kicking around - I'll try and add them to the Tomcat 7 code base.

> TCK helps here, but there are cases that it does not catch. I do not
> have TCK access, but I see from bug reports that were fixed thus far.

That is easy to arrange if you would like TCK access.

> Also the behavior triggered by
> org.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING property is
> not tested by TCK.

Yep. More test cases required...

> 4.
>> parsing. I've refactored this part and am currently looking to see if I
>> can refactor the function validation code to use the EL parser. My
> Currently when generating Java code Jasper evaluates the composite
> expressions in the following way:
> a) It parses an expression and splits it into Eval and Literal
> expressions, according to JSP escaping rules.
> b) Literal expressions are processed as is, and only Eval expressions
> are passed to the EL interpreter.
> c) The result is concatenated, and has to be coerced to the expected type.
> This becomes a bit complicated.

It gets worse as Jasper then parses the Eval expression as well as
passing it to the EL code.

> There could be another implementation: re-escape the Literal
> expression (e.g. replacing '\' with ${'\\'}), recombine the
> expressions and pass it to the EL interpreter.

That is probably worth considering once the other changes are in place
to see if it simplifies things at all.

> Also, in the Java code generated from
> /examples/jsp/jsp2/el/composite.jsp (of TC7)
> I see some example, where composite EL expression is evaluated as is.
> I suspect that it will exhibit the quoting bugs, but I have not payed
> it much attention yet:
>> org.apache.jasper.runtime.JspRuntimeLibrary.handleSetPropertyExpression(
>> _jspx_page_context.findAttribute("values"), "long", "000${1}${7}",
>> _jspx_page_context, null);
> The above is generated from
> <jsp:setProperty name="values" property="long" value="000${1}${7}"/>
> We also have

Yep. Need to look at that too.


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

View raw message