[
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)
