[
https://issues.apache.org/jira/browse/WW-5789?focusedWorklogId=1049414&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1049414
]
ASF GitHub Bot logged work on WW-5789:
--------------------------------------
Author: ASF GitHub Bot
Created on: 22/Oct/26 19:58
Start Date: 22/Oct/26 19:58
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #2050:
URL: https://github.com/apache/struts/pull/2050
Fixes [WW-5789](https://issues.apache.org/jira/browse/WW-5789)
## What was wrong
A ModelDriven action in a package extending `rest-default` lost form-bound
values on every model property that has a non-null constructor default, while
JSON bodies and `struts.parameters.requireAnnotations=false` both worked.
Regression from 7.2.0.
Since WW-5626, `ContentTypeInterceptor` runs a two-phase copy for every
handler that is not an `AuthorizationAwareContentTypeHandler` when
`requireAnnotations=true`: build a fresh instance via the no-arg constructor,
let the handler fill it, copy every non-null property onto the real target.
`FormUrlEncodedHandler`, `MultipartFormDataHandler` and `HtmlHandler` have a
no-op `toObject`, so the fresh instance carried only constructor defaults, and
those were copied over what `params` had bound one interceptor earlier. Null
defaults are skipped by the copy, which is exactly the reporter's "unless it is
null by default".
## Change
- The three no-op handlers declare `AuthorizationAwareContentTypeHandler`,
so the interceptor takes the direct path for them. They bind nothing, so there
is nothing to authorize after the fact.
- The marker's Javadoc admits the no-op case and states that a subclass
overriding `toObject` to deserialize inherits the declaration and must honor
the context itself.
- `ContentTypeInterceptorIntegrationTest`: three tests on a ModelDriven
fixture with a constructor default, one per handler. Each failed with
`expected:<[bound-by-params]> but was:<[new]>` before the change.
## Left out on purpose
The two-phase copy itself still cannot tell "the body said X" from "the
constructor said X". A handler that stays on that path (`XStreamHandler`, which
is opt-in, and any third-party handler) still copies a constructor default over
a params-bound or `prepare()`-loaded value whenever the body omits that
property. Fixing that means comparing against a pristine fresh instance inside
`copyAuthorizedProperties`, which changes the semantics of the authorization
copy and deserves its own ticket.
## Verification
- `plugins/rest` suite with core compiled from the branch: 226 tests, 0
failures.
- Security review of the diff: no findings. The change only removes a
spurious write; no request body reaches a setter it could not reach before.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1049414)
Remaining Estimate: 0h
Time Spent: 10m
> default values are restored for some properties on ModelDriven bean
> -------------------------------------------------------------------
>
> Key: WW-5789
> URL: https://issues.apache.org/jira/browse/WW-5789
> Project: Struts 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.2.1, 7.3.0, 7.4.0
> Reporter: Patrice DUROUX
> Assignee: Lukasz Lenart
> Priority: Minor
> Fix For: 7.5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello,
> Some curl tests on the same ModelDriven action (in a package that extends
> both rest-default and json-default) have changed their result regarding the
> Struts version and it is summary by:
> ||Client query||Struts 7.1.1||upper||
> |JSON|done|done|
> |form-data|done|failed|
> Since WW-5626 (or perhaps some related changes), the model bean of a
> ModelDriven action does not retain the values set by ParameterInterceptor
> unless it is null by default in a fresh instance otherwise the default value
> (in its constructor) overrides the client value.
> Looking at:
> https://struts.apache.org/core-developers/struts-parameter-annotation
> One solution we found is to set:
> {{struts.parameters.requireAnnotations=false}}
> But on model bean it should not be necessary to annotate if we understand
> well the documentation.
> Â
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
