Bug 47413 - difference in composite ${a}${b} EL expressions between 6.0.18 and 6.0.20

[Konstantin Kolinko <kn...@gmail.com>]

Regarding the issue #47413 ,

[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=47413#c8

The problem there is with method Generator.attributeValueWithEL(),
that was introduced in rev.708165

I have fixed the first issue, mentioned in comment #8 in [1], and it
is now proposed for backport to 6.0,
but to fix the second one there, I need to generate JSP code that
coerces the string value to the expected type according to EL coercion
rules.

I do not see how to easily implement that.  Maybe somebody has an idea?


1) EL coercion rules are best implemented by
o.a.el.lang.ELSupport.coerceToType(obj, type),
but as far as I understand catalina.policy, a JSP page is not allowed
to call that class.

Either a wrapper method should be added (where?), or the policy be changed.


JspRuntimeLibrary.convert(String,String,Class,Class) in package
o.a.jasper.runtime
looks similar to what is needed, but actually it is wrong:
 when converting to a Boolean value it interprets "on" as true, but
according to EL rules that should be false (as Boolean.valueOf("on")
is false).
I think that it serves some other purpose.

Generator.GenerateVisitor.convertString(Class, String, String, Class,
boolean) in package o.a.jasper.compiler  does conversion at compile
time, not at run time. I won't like to reimplement all those
conversion rules.


2) Alternative way:

The comment in Generator.attributeValueWithEL() says that this method
is needed to prevent unescaping of literals that are outside of EL
expressions, as blindly passing them over to EL processor will result
in unescaping.

Maybe we can double-escape those literals, so that when EL processor
performs their unescaping it will restore their original values?
If so, we can create one composite EL expression and pass it over to
EL processor, and it will evaluate it and perform all necessary
coercions.

Is this a plausible route to resolve this?

What escaping is meant there? Is it \$, \#, \', \" ?


PS: I prepared an amendment to the examples webapp, that demonstrates
composite EL expressions, and serves an a reproducer for this issue. I
planned to resolve the issue first before proposing it, but as I am
stuck here I will commit it. It will need some cleanup, though, and it
is night now,  so that will be in ca. 12 hours.

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Bug 47413 - difference in composite ${a}${b} EL expressions between 6.0.18 and 6.0.20

[Mark Thomas <ma...@apache.org>]

Konstantin Kolinko wrote:
> but to fix the second one there, I need to generate JSP code that
> coerces the string value to the expected type according to EL coercion
> rules.
> 
> I do not see how to easily implement that.  Maybe somebody has an idea?

Some thoughts in-line.

> 1) EL coercion rules are best implemented by
> o.a.el.lang.ELSupport.coerceToType(obj, type),
> but as far as I understand catalina.policy, a JSP page is not allowed
> to call that class.

Correct.

> Either a wrapper method should be added (where?), or the policy be changed.
> 
> JspRuntimeLibrary.convert(String,String,Class,Class) in package
> o.a.jasper.runtime
> looks similar to what is needed, but actually it is wrong:
>  when converting to a Boolean value it interprets "on" as true, but
> according to EL rules that should be false (as Boolean.valueOf("on")
> is false).
> I think that it serves some other purpose.

The only place I see that code being used is in o.a.j.c.Generator. I am pretty
sure than is a bug that needs to be fixed. It has been like that since the very
first Tomcat 3.0.x code import but I can't see any good reason in the specs for
converting "on" to true.

> Generator.GenerateVisitor.convertString(Class, String, String, Class,
> boolean) in package o.a.jasper.compiler  does conversion at compile
> time, not at run time. I won't like to reimplement all those
> conversion rules.


+1 :)

> 2) Alternative way:
> 
> The comment in Generator.attributeValueWithEL() says that this method
> is needed to prevent unescaping of literals that are outside of EL
> expressions, as blindly passing them over to EL processor will result
> in unescaping.
> 
> Maybe we can double-escape those literals, so that when EL processor
> performs their unescaping it will restore their original values?
> If so, we can create one composite EL expression and pass it over to
> EL processor, and it will evaluate it and perform all necessary
> coercions.
> 
> Is this a plausible route to resolve this?

I looked at this when I worked on the EL Parser issues. If memory serves me
correctly this had issues around correctly handling unescaped sequences like
'\$', '\\$', '\\\$' etc. You may have better luck than I did.

> What escaping is meant there? Is it \$, \#, \', \" ?

You'll also need to escape \.

Overall, I think a solution based on
JspRuntimeLibrary.convert(String,String,Class,Class) is the way to go. That
said, you are the one doing the work so feel free to ignore me ;)

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org