Bug 38797 - 5.5.12 and 5.5.15 emit different code on <jsp:getProperty>
Summary: 5.5.12 and 5.5.15 emit different code on <jsp:getProperty>
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Jasper (show other bugs)
Version: 5.5.14
Hardware: Other other
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-27 18:40 UTC by Kurt Huwig
Modified: 2009-11-30 16:32 UTC (History)
2 users (show)



Attachments
Here is a test case with differents entries. (10.10 KB, application/octet-stream)
2007-03-12 03:07 UTC, tdeverdiere
Details
Example of jsp:getProperty not working correctly (28.65 KB, application/octet-stream)
2009-08-20 12:26 UTC, Rich Naylor
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kurt Huwig 2006-02-27 18:40:15 UTC
Compiling this code:

<jsp:getProperty name="person" property="name"/>

results in this with the Jasper of Tomcat 5.5.15:

out.write(org.apache.jasper.runtime.JspRuntimeLibrary.toString(org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(_jspx_page_context.getAttribute("person",
PageContext.PAGE_SCOPE), "name")));

And this with the Jasper of Tomcat 5.5.12 and before (checked 5.5.12, 5.0.28 and
some versions in between):

out.write(org.apache.jasper.runtime.JspRuntimeLibrary.toString(org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(_jspx_page_context.findAttribute("person"),
"name")));

My property is in the session's scope, so the property is not found and an
exception is thrown:

SCHWERWIEGEND: Servlet.service() for servlet jsp threw exception
org.apache.jasper.JasperException: Attempted a bean operation on a null object.
	at
org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(JspRuntimeLibrary.java:601)
	at
org.apache.jsp.title_jsp._jspx_meth_iku_restricted_0(org.apache.jsp.title_jsp:146)
	at org.apache.jsp.title_jsp._jspService(org.apache.jsp.title_jsp:104)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
	at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
	at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
	at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
	at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
	at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)

BTW: version 5.5.15 is missing in the bugzilla, so I selected 5.5.14
Comment 1 william.barker 2006-02-27 20:39:26 UTC

*** This bug has been marked as a duplicate of 37933 ***
Comment 2 tdeverdiere 2007-03-09 08:52:28 UTC
I noticed too the change. The behaviour is in Tomcat 5.5.20, here is the
following exception :
org.apache.jasper.JasperException: Tentative d''opération bean sur un objet nul.
org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(JspRuntimeLibrary.java:601)
	org.apache.jsp.test3_005f2_jsp._jspService(test3_005f2_jsp.java:77)

This not the same bug as 37933. It is an error that is due to the bug correction
:(. (well but the correction of the bug 37933 is not easy)
I explain.

I have a custom tag that defines a scripting variable. This variable is in a
request attribute. The custom tag library defines a scripting variable with a
Tag Extra Info class. The TLD declares a tag with the tag class implementation
and the Tag Extra Info class implementation.
The tag is named "variable".
The tag has 3 attributes "id", "className", "scopeIn".

The object "Song" has a property "title".

Here is where it fails : 
<%@ taglib uri="http://www.scort.com/test" prefix="test" %> 
...
<!-- The variable is set in the scope request -->
<test:variable id="mysong" className="tomcat.test.Song" scopeIn="request" />
...
Title : <jsp:getProperty name="mysong" property="title" />

=> mysong is said to be null

But here is a page where it works : 
<%@ taglib uri="http://www.scort.com/test" prefix="test" %> 
...
<!-- The variable is set in the scope page -->
<test:variable id="mysong" className="tomcat.test.Song" scopeIn="page" />
...
Title : <jsp:getProperty name="mysong" property="title" />

Finally it always works with jsp:useBean :

<jsp:useBean id="mysong" class="tomcat.test.Song" scope="request" />
...
Title : <jsp:getProperty name="mysong" property="title" />


The custom library i wrote defined a VariableInfo that expose a scripting
variable into the page. So i thought (think) it was the key to allow it into the
 jspGetProperty.

--------------------------------------

Reference in the specification JSP 2.0 JSP5.3 :

"The value of the name attribute in jsp:setProperty andjsp:getProperty will
refer to an object that is obtained from the pageContext object through its
findAttribute method."

Hope it helps.
Comment 3 tdeverdiere 2007-03-12 03:07:42 UTC
Created attachment 19695 [details]
Here is a test case with differents entries.

Here is a test case with differents entries.
Test 1 and 2 are with useBean.
Test 3 and 4 are with a custom tag library. 
And the Test 3 fails while the test 2 pass and the test 4 too.
Test 1 : test1.jsp
Test 2 : test2_1.jsp
Test 3 : test3_1.jsp
Test 4 : test4_1.jsp
Comment 4 tdeverdiere 2007-09-20 08:53:41 UTC
Could you please correct this bug in Tomcat 6 ?

Thanks
Thomas
Comment 5 Mark Thomas 2009-07-05 04:38:22 UTC
Thanks for the test case.

I reverted the fix for 37933 and implemented an alternative that doesn't have the issue described here. It also throws an error at translation time rather than runtime.

The fix has been made in trunk and proposed for 6.0.x and 5.5.x
Comment 6 Mark Thomas 2009-07-09 02:13:41 UTC
This has been fixed in 5.5.x and will be in 5.5.28 onwards
Comment 7 Rich Naylor 2009-08-19 08:55:38 UTC
(In reply to comment #6)
> This has been fixed in 5.5.x and will be in 5.5.28 onwards

I believe the code introduced org.apache.jasper.compiler.Generator has missed a point and introduced another issue. If you look at the changes made to GeneratorVisitor.visit(Node.GetProperty n), code was added to check if the varInfoNames Set contains the variable name used in the getProperty. If this variable name is not found, a JasperException is thrown. However, what I believe is missing is a check of the parent hierarchy to see if it was declared at a higher level. In the case I have an issue with, the jsp:getProperty does not have any varInfoNames declarations, but the parent (which is a customTag) does contain the proper declarations. The proper declaration would have been found if the check had traversed to the parent.
Comment 8 Mark Thomas 2009-08-19 09:07:24 UTC
Can you provide the source for a simple test case that demonstrates the issue you are seeing?
Comment 9 Rich Naylor 2009-08-20 12:26:14 UTC
Created attachment 24155 [details]
Example of jsp:getProperty not working correctly
Comment 10 Mark Thomas 2009-08-29 06:38:46 UTC
Thanks for the test case.

A number of the files include headers that indicate that the source files are not to be distributed without "express written consent". Please confirm you have the necessary rights to distribute these files asap else the test case will have to be removed from bugzilla.

 The test case includes a TLD file in the META-INF directory. This is not the correct location for TLDs in a WAR file and will be ignored - see JSP.7.3.1
 
 The analysis as to the cause of the regression is not quite right. It is not necessary to scan the node hierarchy. The problem is that the list of introduced variables was updates after, rather than before, the tag body was processed. This has been fixed in trunk and proposed for 5.5.x and 6.0.x
Comment 11 Rich Naylor 2009-09-09 08:22:25 UTC
(In reply to comment #10)
> Thanks for the test case.
> 
> A number of the files include headers that indicate that the source files are
> not to be distributed without "express written consent". Please confirm you
> have the necessary rights to distribute these files asap else the test case
> will have to be removed from bugzilla.
> 
>  The test case includes a TLD file in the META-INF directory. This is not the
> correct location for TLDs in a WAR file and will be ignored - see JSP.7.3.1
> 
>  The analysis as to the cause of the regression is not quite right. It is not
> necessary to scan the node hierarchy. The problem is that the list of
> introduced variables was updates after, rather than before, the tag body was
> processed. This has been fixed in trunk and proposed for 5.5.x and 6.0.x

Sorry about the header issue, I should have stripped those notices out. I do have the necessary rights to distribute these files. 

So it it sounds like you already have a fix in progress for the case I am referencing. Is there some other bug id this is associated with, or is it part of 38797 ? 

The TLD location is an oversight, but apparently the tags are still being found.
Comment 12 Mark Thomas 2009-09-10 04:59:24 UTC
Thanks for confirming the test case is OK.

The fix will be tracked using this bugzilla issue.
Comment 13 Mark Thomas 2009-09-11 05:22:34 UTC
*** Bug 47822 has been marked as a duplicate of this bug. ***
Comment 14 Mark Thomas 2009-11-02 13:30:18 UTC
This has been fixed in 6.0.x and will be included in 6.0.21 onwards.
Comment 15 Mark Thomas 2009-11-30 16:32:44 UTC
Fixed in trunk. Many thanks.