[
https://issues.apache.org/jira/browse/WW-5535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated WW-5535:
------------------------------
Description:
The ActionProxy.isMethodSpecified() method is documented as:
{noformat}
Gets status of the method value's initialization.
Returns: true if the method returned by getMethod() is not a default
initializer value.
{noformat}
However, the implementation in DefaultActionProxy has a different behavior:
{code:java}
private void resolveMethod() {
// if the method is set to null, use the one from the configuration
// if the one from the configuration is also null, use "execute"
if (StringUtils.isEmpty(this.method)) {
this.method = config.getMethodName();
if (StringUtils.isEmpty(this.method)) {
this.method = ActionConfig.DEFAULT_METHOD;
}
methodSpecified = false;
}
} {code}
methodSpecified is set to false not only if the default value is used, but also
\{*}if methodName is specified via config{*}.
This method seems to have been introduced long ago as a patch for some DMI
behavior regression: WW-3628
The issue happens for example if you specify an action like
{code:java}
<action name="example-*" class="aClass" method="aMethod"/>
{code}
since the method value is resolved later by wildcard matching.
The HttpMethodInterceptor uses isSpecifiedMethods to decide when to process the
invocation:
{code:java}
if (invocation.getProxy().isMethodSpecified()) {
Method method =
action.getClass().getMethod(invocation.getProxy().getMethod());
// doIntercept...
}{code}
thus skipping the validation for actionNames with wildcards.
I'm not really sure if isMethodSpecified is wrong or has misleading
documentation. I'm not even sure why the HttpMethodInterceptor should skip
validation on the default execute methods.
A fix might be just assessing the existence of
invocation.getProxy().getMethod() instead on relying on isMethodSpecified, but
before submitting a pr I'd like the opinion on the maintainers.
was:
The ActionProxy.isMethodSpecified() method is documented as:
{noformat}
Gets status of the method value's initialization.
Returns: true if the method returned by getMethod() is not a default
initializer value.{noformat}
However, the implementation in DefaultActionProxy has a different behavior:
{code:java}
private void resolveMethod() {
// if the method is set to null, use the one from the configuration
// if the one from the configuration is also null, use "execute"
if (StringUtils.isEmpty(this.method)) {
this.method = config.getMethodName();
if (StringUtils.isEmpty(this.method)) {
this.method = ActionConfig.DEFAULT_METHOD;
}
methodSpecified = false;
}
} {code}
methodSpecified is set to false not only if the default value is used, but also
\{*}if methodName is specified via config{*}.
This method seems to have been introduced long ago as a patch for some DMI
behavior regression: https://issues.apache.org/jira/browse/WW-3628
The issue happens for example if you specify an action like
{code:java}
<action name="example-*" class="aClass" method="aMethod"/>
{code}
since the method value is resolved later by wildcard matching.
The HttpMethodInterceptor uses isSpecifiedMethods to decide when to process the
invocation:
{code:java}
if (invocation.getProxy().isMethodSpecified()) {
Method method =
action.getClass().getMethod(invocation.getProxy().getMethod());
// doIntercept...
}{code}
thus skipping the validation for actionNames with wildcards.
I'm not really sure if isMethodSpecified is wrong or has misleading
documentation. I'm not even sure why the HttpMethodInterceptor should skip
validation on the default execute methods.
A fix might be just assessing the existence of
invocation.getProxy().getMethod() instead on relying on isMethodSpecified, but
before submitting a pr I'd like the opinion on the maintainers.
> HttpMethodInterceptor does not work with action names using wildcards
> ---------------------------------------------------------------------
>
> Key: WW-5535
> URL: https://issues.apache.org/jira/browse/WW-5535
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 6.7.0, 7.0.0
> Reporter: Riccardo Proserpio
> Assignee: Lukasz Lenart
> Priority: Major
> Fix For: 6.9.0, 7.2.0
>
>
> The ActionProxy.isMethodSpecified() method is documented as:
> {noformat}
> Gets status of the method value's initialization.
> Returns: true if the method returned by getMethod() is not a default
> initializer value.
> {noformat}
> However, the implementation in DefaultActionProxy has a different behavior:
>
> {code:java}
> private void resolveMethod() {
> // if the method is set to null, use the one from the configuration
> // if the one from the configuration is also null, use "execute"
> if (StringUtils.isEmpty(this.method)) {
> this.method = config.getMethodName();
> if (StringUtils.isEmpty(this.method)) {
> this.method = ActionConfig.DEFAULT_METHOD;
> }
> methodSpecified = false;
> }
> } {code}
> methodSpecified is set to false not only if the default value is used, but
> also \{*}if methodName is specified via config{*}.
> This method seems to have been introduced long ago as a patch for some DMI
> behavior regression: WW-3628
> The issue happens for example if you specify an action like
> {code:java}
> <action name="example-*" class="aClass" method="aMethod"/>
> {code}
> since the method value is resolved later by wildcard matching.
>
>
> The HttpMethodInterceptor uses isSpecifiedMethods to decide when to process
> the invocation:
>
> {code:java}
> if (invocation.getProxy().isMethodSpecified()) {
> Method method =
> action.getClass().getMethod(invocation.getProxy().getMethod());
> // doIntercept...
> }{code}
> thus skipping the validation for actionNames with wildcards.
> I'm not really sure if isMethodSpecified is wrong or has misleading
> documentation. I'm not even sure why the HttpMethodInterceptor should skip
> validation on the default execute methods.
> A fix might be just assessing the existence of
> invocation.getProxy().getMethod() instead on relying on isMethodSpecified,
> but before submitting a pr I'd like the opinion on the maintainers.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
