[
https://issues.apache.org/jira/browse/WW-5535?focusedWorklogId=1020952&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1020952
]
ASF GitHub Bot logged work on WW-5535:
--------------------------------------
Author: ASF GitHub Bot
Created on: 19/May/26 07:54
Start Date: 19/May/26 07:54
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #1692:
URL: https://github.com/apache/struts/pull/1692
## Summary
Closes the integration test gap identified in the [WW-5535
research](https://github.com/apache/struts/blob/main/thoughts/shared/research/2026-02-22-WW-5535-http-method-interceptor-wildcard.md):
no test exercised `HttpMethodInterceptor` against a **real**
`DefaultActionProxy` resolving a wildcard action with an unannotated method.
Together with the existing `MockActionProxy`-based regression tests, this
locks in both halves of the fix:
- `DefaultActionProxy.resolveMethod()` sets `isMethodSpecified()=true` for
wildcard-resolved methods — WW-5535 / #1592
- `HttpMethodInterceptor` falls back to class-level annotations when the
resolved method is unannotated — #1690
## What the test does
Uses the existing `xwork-test-allowed-methods.xml`:
```xml
<action name="Wild-*" class="HttpMethodsTestAction" method="{1}">
```
`HttpMethodsTestAction` carries class-level `@AllowedHttpMethod(POST)`. URL
`Wild-execute` resolves to `ActionSupport.execute()` — no method-level HTTP
annotation. The integration test:
1. Creates a real proxy via `actionProxyFactory.createActionProxy("",
"Wild-execute", null, ...)`
2. Asserts `proxy.getMethod() == "execute"` and `proxy.isMethodSpecified()
== true` (sanity-checks the WW-5535 wiring)
3. Runs a real `HttpMethodInterceptor` against `proxy.getInvocation()` with
a GET request
4. Asserts `bad-request` — class-level annotation still enforced
Only the negative (GET) case is covered: it returns before
`invocation.invoke()`, so the test stays a focused integration check without
dragging the whole interceptor stack in. The positive POST counterpart is
already covered by the unit tests added in #1690.
Fixes [WW-5535](https://issues.apache.org/jira/browse/WW-5535) test gap.
## Test plan
- [x] \`mvn test -DskipAssembly -pl core -Dtest=HttpMethodInterceptorTest\`
— 16/16 pass
- [ ] CI green
Issue Time Tracking
-------------------
Worklog Id: (was: 1020952)
Time Spent: 1h (was: 50m)
> 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
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> 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)
