[jira] [Closed] (WW-3267) ParamsInterceptor doesn't populate request parameters on certain situations

["Lukasz Lenart (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WW-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukasz Lenart closed WW-3267.
-----------------------------
    Resolution: Won't Fix

> ParamsInterceptor doesn't populate request parameters on certain situations
> ---------------------------------------------------------------------------
>
>                 Key: WW-3267
>                 URL: https://issues.apache.org/jira/browse/WW-3267
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Core Interceptors
>    Affects Versions: 2.1.6
>         Environment: Tested on windows XP, java 1.5 and Tomcat 6
>            Reporter: Ricardo Tercero Lozano
>            Priority: Major
>             Fix For: 6.1.0
>
>
> I've discovered a situation where ParamsInterceptor doesn't populate the action bean attributes.
> This is the situation:
> 1) Webapp with struts2 deployed
> 2) Interceptor stack redefined to have an own interceptor before default stack (just before params interceptor indeed):
> <interceptor-ref name="serverDate" />
> <interceptor-ref name="defaultStack">
>     <param name="validation.includeMethods">validar*</param>
>     <param name="workflow.includeMethods">validar*</param>					
> </interceptor-ref>
> Where serverDate is an interceptor that only puts an object into de ValueStack.
> 3) Test, for example, file upload interceptor. So put the 3 attributes onto a bean with setters/getters
> 	public File anexo;
> 	public String anexoContentType;
> 	public String anexoFileName;
> 4) Run it, and when execution control stops on action method, the attributes are not filled in.
> After some debugging, I can add another restriction to this test case: the request params have to be direct action attributes (just 'address' instead of 'form.address').
> This is the execution sequence:
> 1.- First, control stops in 'doIntercept' method of ParamsInterceptor.
> 2.- on line 173, method retrieveParameters is called, returning the parameter list.
> 3.- on line 186, ac.getValueStack() is called. In debug mode, here the bad situation can be detected.
> 4.- on line 187, setParameters() method is called.
> 5.- on this method, on line 273 a newStack.setValue() is called.
> So, attribute population is handled through setValue on the ValueStack.
> In both, correct and error situation (no parameters inserted into ValueStack before paramsInterceptor) the call to setValue ends on method 'setProperty' of com.opensymphony.xwork.ognl.accessor.CompoundRootAccessor. This method iterates over the elements of the root property from OgnlStackValue, which is a CompoudRoot object. This CompoundRoot is, in fact, an array with StackValue root elements. CompoundRootAccessor.setProperty, sets a property on the first available element of the CompoundRoot with special programming for 2 object types:
> 1.- Objects with a set accessor available for the parameter to set.
> 2.- Maps to insert the parameter.
> In the correct situation, the composition of the CompoundRoot is like this:
> [0] ActionBean
> [1] DefaultTextProvider
> so the first available element of the CompoundRoot array with a setter for the property is the ActionBean resulting in a call to the bean setter property.
> In the erro situation, with an interceptor inserting an object into the ValueStack previous to paramsInterceptor execution, the composition of the CompoundRoot is:
> [0] HashMap<K,V>  (ValueStack root elements).
> [1] ActionBean
> [2] DefaultTextProvider
> so the first available element of the CompoundRoot array with a setter is the HashMap resulting in the request parameters inserted into the root of the ValueStack, but not the ActionBean.
> This is so, only for direct attributes of the action bean. If the named parameter has dots '.' for object navigation, the OgnlStackValue sets properties right.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)