struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lukasz Lenart (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (WW-4323) Ability to accept params purely by implementing ParamNameAware is broken
Date Mon, 14 Apr 2014 13:07:15 GMT

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

Lukasz Lenart commented on WW-4323:
-----------------------------------

The problem was that this change (which gave user more power, ie. && => ||) was
breaking change for some others guys. I would like to return to this solution as it's a better
way to handle custom parameters per action. Also ParametersInterceptor is a monster right
now, with a lot of logic inside, so I must develop some nice, pluggable solution where user
can write handler and decide when to use && and when || - but this will happened in
2.5 probably.


> Ability to accept params purely by implementing ParamNameAware is broken
> ------------------------------------------------------------------------
>
>                 Key: WW-4323
>                 URL: https://issues.apache.org/jira/browse/WW-4323
>             Project: Struts 2
>          Issue Type: Bug
>    Affects Versions: 2.3.16.1
>         Environment: struts2 version 2.3.16.1
>            Reporter: Kyle Braak
>             Fix For: 2.5
>
>
> The ability to accept params purely by implementing ParamNameAware is broken.
> Relates to https://issues.apache.org/jira/browse/WW-3866 which is when this feature was
added for version 2.3.5
> The commit that breaks this feature is: https://github.com/apache/struts/commit/4e98aaaa1b08cc37374d06e77cf78000d98c5ff0
> Description:
> Prior to this change/2.3.16.1 it was quite convenient to define what parameters my action
should accept, by implementing ParameterNameAware#acceptableParameterName. With this change,
there is the additional requirement that the parameter names must also satisfy acceptableName(name).
> In the ParametersInterceptor javadoc, it says: "if you wish to apply a global rule that
isn't implemented in your action, then you could extend this interceptor and override the
{@link #acceptableName(String)} method." So this isn't suitable for customizing a single action.
> Looking more carefully at the code, another alternative to defining what parameters my
action can accept, looks to be via populating the ParametersInterceptor's field acceptParams.
Apparently this could be done in the interceptor stack from what I have read here: http://struts.apache.org/release/2.3.x/docs/parameters-interceptor.html
> By forcing one to populate acceptParams, and also implement ParameterNameAware#acceptableParameterName
it becomes quite difficult to add custom behavior. I understand people should fully understand
what they are doing due to the security risks involved, but it is probably safer to define
the behavior in a single place.
> I'd greatly appreciate your help understanding how to adapt to this change. In the meantime,
I'll have to continue using 2.3.15.3
> Thanks



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message