struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Ström (JIRA) <j...@apache.org>
Subject [jira] [Commented] (WW-4083) ParametersInterceptor acceptParamNames and ParameterNameAware's acceptableParameterName conflicts
Date Tue, 28 May 2013 11:07:21 GMT

    [ https://issues.apache.org/jira/browse/WW-4083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668233#comment-13668233
] 

Johan Ström commented on WW-4083:
---------------------------------

Yes, I've now fallen back on using the default acceptParamNames, and using a overridden ParametersInterceptor
as per WW-4068, with an isAcceptableParameter implemented to do it the old way, that is if
we have a PNA, it must accept it as well.

I did try to set all the params I wanted in acceptParamNames, this worked out for simple strings
but when it got to nested objects (i.e. user.firstname which would do getUser().setFirstname())
it did not work as expected for some reason. The simple way was to just re-introduce the old
behavior.
                
> ParametersInterceptor acceptParamNames and ParameterNameAware's acceptableParameterName
conflicts
> -------------------------------------------------------------------------------------------------
>
>                 Key: WW-4083
>                 URL: https://issues.apache.org/jira/browse/WW-4083
>             Project: Struts 2
>          Issue Type: Bug
>    Affects Versions: 2.3.14.2
>            Reporter: Johan Ström
>             Fix For: 2.3.15
>
>
> If the ParameterInterceptor config element 'acceptParamNames' does not match a name,
but the ParameterNameAware accepts it, the interceptor will fail to set it on the valuestack.
> In ParametersInterceptor, the acceptParamNames config element is used in two places on
each interception:
> * to fill up acceptableParameters. This is based on both acceptParamNames config, AND
any ParameterNameAware's acceptableParameterName(Strings) method.
> * to setAcceptProperties on the MemberAccessValueStack. This ONLY uses the acceptParamNames
config.
> The problem occurs if acceptParamNames config rejects a param, but acceptableParameterName(String)
accepts it. The ParameterInterceptor will go try to set the value on the stack (since it was
accepted by the ParameterNameAware), but the stack will reject it since setAcceptProperites
is based on acceptParamNames only.
> Not sure what the proper fix here is, but at least it explains the problem I'm having
and what other people might have.
> The reason it was not accepted by the config was that after the WW-3973 change, any parameter
accepted by EITHER the config or the ParameterNameAware is passed on. I tried to guard against
this by setting a very restrictive config for acceptableParameters (i.e. a dummy value which
did not let ANY parameter througH), with the idea that the ParameterNameAware would allow
it.
> The quick fix for me would be to just accept the parameter name explicitly in the config,
and skip the ParameterNameAware part, but I still want to report it as it is probably not
what is expected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message