Bug 47413 - There is difference in composite ${a}${b} EL expressions between 6.0.18 and 6.0.20
Summary: There is difference in composite ${a}${b} EL expressions between 6.0.18 and 6...
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Servlet & JSP API (show other bugs)
Version: 6.0.20
Hardware: PC Windows Vista
: P2 critical (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
: 47487 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-06-24 01:45 UTC by masatonagai
Modified: 2009-09-07 07:27 UTC (History)
2 users (show)



Attachments
example jsp to reproduct the bug (1.96 KB, text/plain)
2009-06-25 01:04 UTC, masatonagai
Details

Note You need to log in before you can comment on or make changes to this bug.
Description masatonagai 2009-06-24 01:45:05 UTC
In Tomcat 6.0.18, <c:out> tag that has undefined reference in its value  (like the following snippet) outputs empty string(""), but in Tomcat 6.0.20 outputs null. This is a critical bug.. Please fix it ASAP.

===
<c:out value="${foo.undefined.bar}" />
===
Comment 1 Xie Xiaodong 2009-06-24 03:22:36 UTC
Sorry, I tweaked the example jsp file in "webapps\examples\jsp\jsp2\jspattribute" a little (both 6.0.18 and 6.0.20), and I got the same result: 

an error page of: 

javax.el.PropertyNotFoundException: Property 'undefined' not found on type jsp2.examples.FooBean
	javax.el.BeanELResolver$BeanProperties.get(BeanELResolver.java:193)
	javax.el.BeanELResolver$BeanProperties.access$400(BeanELResolver.java:170)
	javax.el.BeanELResolver.property(BeanELResolver.java:279)
	javax.el.BeanELResolver.getValue(BeanELResolver.java:60)
	javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
	org.apache.el.parser.AstValue.getValue(AstValue.java:118)
        ..................


so could you please send us your source code that could reproduce this bug?
Comment 2 masatonagai 2009-06-24 18:29:44 UTC
Ooops, sorry. This is correct example.
===
<c:out vlaue="${undefined}" />
===
Comment 3 Xie Xiaodong 2009-06-24 21:09:45 UTC
sorry, I found that the behaviors of tomcat-6.0.18 and tomcat-6.0.20 are the same. Could you please check again? 

You could just tweak "webapps\examples\jsp\jsp2\jspattribute\ jspattribute.jsp" a little, just add "<c:out value="${undefined}"/>", and you'll find that the behaviors are the same.
Comment 4 masatonagai 2009-06-25 01:04:26 UTC
Created attachment 23875 [details]
example jsp to reproduct the bug 

Ok, this is the example jsp (webapps\examples\jsp\jsp2\jspattribute\jspattribute.jsp) that I edited to reproduct the bug I said.

(sorry.. my jsp snippet example I wrote was wrong again.. but this isn't!)
Comment 5 Xie Xiaodong 2009-06-25 01:56:41 UTC
OK, thanks for the example. 

Here is a work-around: 

<c:if test="${foo}">${foo}</c:if>

from which you could get the same behavior as 6.0.18. 

Sorry for the inconvenience. 

And We'll check that.
Comment 6 Konstantin Kolinko 2009-07-18 20:06:35 UTC
I've debugged the issue
(the one, demonstrated by example jsp attached in comment #4)

If you look to what java code is generated for
<c:set var="foo" value="${foo}${undefined}"/>
you will see, that the first part of the value expression is constrained to Object. That is wrong, because both ${foo} and ${undefined} should be constrained to String.


I fixed it in trunk and proposed for 6.0.
Comment 7 Konstantin Kolinko 2009-07-18 20:08:38 UTC
*** Bug 47487 has been marked as a duplicate of this bug. ***
Comment 8 Konstantin Kolinko 2009-07-22 13:32:26 UTC
I renamed this issue, as it is a bug with EL expressions, not with c:out.

There is one additional issue in the same piece of code (Generator#attributeValueWithEL()):

According with the specification, the components of a composite EL expression, such as ${a}${b}, are evaluated from left to right, and each one is coerced to String. Those strings are concatenated, and the result is coerced to the expected type.

The first issue, described in comment #6, is that the first component was not coerced to String.
The second issue is that the result of concatenation is not coerced to the expected type.

It works in 6.0.18 and current 5.5.x.
These issues were introduced in rev. 708165.
Comment 9 Mark Thomas 2009-09-07 07:27:57 UTC
This has been fixed in 6.0.x and will be included in 6.0.21 onwards.