[ 
https://issues.apache.org/struts/browse/WW-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41482
 ] 

Jeremy Mikola commented on WW-2044:
-----------------------------------

The set/get types _do_ match in this case, though.  They just are not correctly 
recognized due to the presence of the third "is" method.

For some reason I cannot explain, it seems that by changing the setCheckbox's 
argument type to a "boolean" primitive, Struts is able to recognize and use it 
properly (with the getCheckbox and isCheckbox methods keeping Boolean and 
boolean return types, respectively).  In this situation, the getCheckbox method 
is still called as it should - despite it's return type differing from the set 
method's argument.

You are correct about the NullPtrException from the "is" method - I just 
whipped that up quickly as an example for the bug report.  The real method body 
does take precautions.

> ParametersInterceptor fails to assign value of form checkbox to Boolean bean 
> attribute  
> ----------------------------------------------------------------------------------------
>
>                 Key: WW-2044
>                 URL: https://issues.apache.org/struts/browse/WW-2044
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Interceptors
>    Affects Versions: 2.0.8
>         Environment: NetBeans IDE 5.5.1 (Bundled Tomcat 5.5.17), Java 1.6
>            Reporter: Jeremy Mikola
>            Priority: Minor
>
> I witnessed a case where the ParametersInterceptor fails to translate the 
> request parameter (via GET method in my tests) and properly set the 
> corresponding attribute for a bean object within an Action.  The ingredients 
> for this error condition were as follows:
> (1) Basic JSP page with a struts checkbox widget.  This allowed me to tamper 
> with the bean.checkbox request parameter via the query string (and observe 
> when it was properly set - as a default value in this case - or not).
>     <%@ taglib uri="/struts-tags" prefix="s" %>
>     <s:checkbox key="bean.checkbox"/>
> (2) A simple Bean class.  Take special note that the isCheckbox() method 
> returns a boolean primitive (I am aware of the Boolean/boolean automagic 
> conversions as of Java 1.5, but this was intentional).
>     public class Bean {
>         private Boolean checkbox;
>     
>         public Bean() { }
>         public Boolean getCheckbox() { return this.checkbox; }
>         public void setCheckbox(Boolean checkbox) { this.checkbox = checkbox; 
> }
>         public boolean isCheckbox() { return this.checkbox.booleanValue(); }
>     }
> (3) Basic action class, inheriting from ActionSupport.  This class contained 
> a private Bean object (named "bean" :), and corresponding get/set methods.
> (4) The struts.xml file was configured to execute the default execute() 
> method for this action, and display the aforementioned JSP page.  The 
> prepareParamsPrepareStack was used as the interceptor stack.
> ----
> Through some debugging, I observed that the Bean$setCheckbox method was never 
> called for the query string:
>     /CheckboxTest.action?bean.checkbox=true
> As a result, the JSP would load and the existing request parameter value 
> would not be pre-loaded into the checkbox.  As you might expect, this extends 
> beyond the inability to populate the checkbox.  In my project, where I 
> discovered this behavior, the parameter was simply never set while processing 
> form POST submissions.
> When changing the Bean$isCheckbox method's return type to Boolean, the 
> ParametersInterceptor functions correctly.  Furthermore, if I leave the 
> method's return value as a boolean, but change its name (e.g. 
> isTheCheckboxSet), the problem is also solved.
> As best I can tell, the presence of a *Checkbox (note the wildcard) method 
> with a return type different from setCheckbox method's argument type is to 
> blame.  Still, I see no logical reason why the offending method should not be 
> allowed to co-exist.
> From what I understand the ParametersInterceptor delegates calling of the set 
> methods to a ValueStack handler, so I would not be surprised if the root 
> cause of this error is found outside of the interceptor class.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to