[
https://issues.apache.org/jira/browse/WW-5751?focusedWorklogId=1043553&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1043553
]
ASF GitHub Bot logged work on WW-5751:
--------------------------------------
Author: ASF GitHub Bot
Created on: 23/Sep/26 13:21
Start Date: 23/Sep/26 13:21
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #1976:
URL: https://github.com/apache/struts/pull/1976
Fixes [WW-5751](https://issues.apache.org/jira/browse/WW-5751)
## Problem
Since 7.3.0, the `ActionFileUploadInterceptor` rejects every upload when
`maximumSize` is set to the literal `null` in an interceptor-ref, with "The
upload validation policy could not be resolved ... unresolved parameters:
maximumSize".
The literal `null` was never converted to a null limit. OGNL cannot convert
the string `"null"` to `Long` (`NoSuchMethodException:
UploadPolicy.setMaximumSize(java.lang.String)`). In 7.2.1 that error was
silently ignored, so `maximumSize` kept its default, which happens to be "no
limit". Since WW-5659, a param that cannot be applied marks the upload policy
unresolved and the upload is rejected. That behaviour is intended and stays.
Before this change there was also no sensible explicit way to lift the
limit: `-1` is applied, but `-1 < file.length()` rejects every file.
## Change
- A negative `maximumSize`, e.g. `-1`, now disables the per-file size check.
`null` still means no limit, as before.
- Javadoc of `ActionFileUploadInterceptor`,
`AbstractFileUploadInterceptor#setMaximumSize` and
`UploadPolicy#setMaximumSize` updated.
- The literal `"null"` still leaves the policy unresolved.
Workaround for 7.3.0 until this ships: `9223372036854775807`
(`Long.MAX_VALUE`), posted on the ticket.
## Tests
- New
`ActionFileUploadInterceptorTest#testAcceptFileWithNegativeMaxSizeHasNoLimit`.
It failed before the change and passes after it.
- `ActionFileUploadInterceptorTest`, `LazyParamInjectorTest`,
`LazyParamsAllowlistTest` and `DefaultInterceptorFactoryTest` pass.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1043553)
Remaining Estimate: 0h
Time Spent: 10m
> null can no longer be passed as parameter to interceptor
> --------------------------------------------------------
>
> Key: WW-5751
> URL: https://issues.apache.org/jira/browse/WW-5751
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 7.3.0
> Reporter: nikos dimitrakas
> Assignee: Lukasz Lenart
> Priority: Major
> Fix For: 7.5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Upgrading from 7.2.1 to 7.3.0 seems to have made a change so that null cannot
> be passed as a parameter to the ActionFileUploadInterceptor.
> I have an interceptor like this:
> {code:java}
> <interceptor name="myFileUpload"
> class="org.apache.struts2.interceptor.ActionFileUploadInterceptor">
> Â Â Â Â Â Â Â Â <param name="maximumSize">128000000</param>
> </interceptor>{code}
> That interceptor is then included in a global interceptor stack called
> myFileUploadStack.
> Later in some specific actions I want to set the maximumSize to null (no
> limit) and I do this:
> {code:java}
> <interceptor-ref name="myFileUploadStack">
> Â Â Â Â <param name="myFileUpload.maximumSize">null</param>
> </interceptor-ref>{code}
> This used to work until 7.2.1, but in 7.3.0 it gives an error:
> The upload validation policy could not be resolved, rejecting the file: file
> "test.pdf"; unresolved parameters: maximumSize
> Looking at the code and the release notes of 7.3.0, I can find that this
> probably relates to the changes made in WithLazyParams.java and
> AbstractFileUploadInterceptor.java (using a policy) as part of WW-5659. But I
> do not see in the release notes anything about this being intended or what
> the migration path would be. The javadoc of WithLazyParams.resolveInto()
> mentions null and empty value becoming unresolved, but not what to do about
> it.
> Obviously, I can set a very large number or create a second interceptor and
> interceptorStack to get around this, but I felt that this should be reported
> so that either it can be fixed, or it can be confirmed as the intended
> behaviour and if so, perhaps write something about it in the release notes
> (under Breaking changes) or in a migration guide.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
