[
https://issues.apache.org/jira/browse/WW-3666?focusedWorklogId=1048000&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1048000
]
ASF GitHub Bot logged work on WW-3666:
--------------------------------------
Author: ASF GitHub Bot
Created on: 17/Oct/26 07:42
Start Date: 17/Oct/26 07:42
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #2039:
URL: https://github.com/apache/struts/pull/2039
Fixes [WW-3666](https://issues.apache.org/jira/browse/WW-3666)
## Summary
Request values with surrounding whitespace (`" 42 "`, `" ACTIVE "`,
`"\t2001-01-10\n"`) were rejected by most built-in converters. Only primitive
`int`/`long` already trimmed, so `long` and `Long` disagreed on the same input.
`Boolean` and `Character` silently misread padded input, with no conversion
error.
`XWorkBasicConverter.convertValue` now trims `String` and `String[]` values
before converting to a non-String scalar target:
- numbers (boxed, `double`/`float`, `BigInteger`, `BigDecimal`), enums,
booleans, `Date`/`java.time`, `Class`
- arrays and collections are not trimmed at the entry; their elements
re-enter `convertValue` and are trimmed per element
- `String`/`Object` targets keep the value untouched (they return before the
trim), and so do `List<String>` elements
- a converter registered for a type still receives the raw value — it is
looked up before the default converter
- `Character`/`char`: `" x"` → `'x'`; whitespace-only input keeps its first
character (`" "` → `' '`), preserving the existing `testConvertChar` behaviour
Whitespace-only input now follows the existing `""` path.
Point 3 of the ticket ("errors should bubble up") is already covered:
conversion failures are recorded and `ConversionErrorInterceptor` turns them
into field errors.
## Behaviour changes worth a migration note (7.5.0)
| Input | Target | Before | After |
|---|---|---|---|
| `" true "` | `Boolean` / `boolean` | `false` | `true` |
| `" x"` | `Character` / `char` | `' '` | `'x'` |
| `""` or `" "` | `Boolean` | `false` | `null` |
| `" "` | boxed numbers, enums, `java.time` | conversion error | `null` (a
`required` validator now reports it instead) |
| `" 42 "` etc. | boxed numbers, enums, `java.time`, arrays | conversion
error | converted value |
Unchanged: `" "` into `int`/`long` is still a conversion error. `" "`
into `double`/`float` gives `null`, which is what `""` already gives there (a
pre-existing quirk in `NumberConverter.convertToDouble`/`convertToFloat`, left
alone).
## Test plan
- [x] New `XWorkConverterTest` cases for numbers, enums, booleans,
characters, `java.time`, `String[]` → `Long[]`, whitespace-only boxed → `null`,
integral primitives → conversion error — the behaviour cases watched failing
before the change
- [x] Guard cases (`String`/`Object`/`String[]` targets untouched, custom
converter receives the raw value) checked by mutation: trimming before the
early return, or in `XWorkConverter` before the lookup, fails them (and the
existing `testConvertChar`)
- [x] `./mvnw test -DskipAssembly -pl core` — 3520 tests, 0 failures
- [x] `./mvnw test -DskipAssembly -DskipITs` (full reactor) — 4860 tests, 0
failures
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1048000)
Remaining Estimate: 0h
Time Spent: 10m
> TypeConverter should trim before conversion to things that are not Strings
> --------------------------------------------------------------------------
>
> Key: WW-3666
> URL: https://issues.apache.org/jira/browse/WW-3666
> Project: Struts 2
> Issue Type: Improvement
> Components: Value Stack
> Affects Versions: 2.2.1.1
> Environment: Standard Struts2 implementation with Jetty
> Reporter: adam brin
> Assignee: Lukasz Lenart
> Priority: Minor
> Fix For: 7.5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For a simple struts2 application, when you pass in parameters that are not
> "Strings" for example Longs or Enums the Xwork2 TypeConverter (and Struts2's
> handling) needs some work.
> Issues:
> * numeric values are not properly parsed if they have space characters
> * enum values are not properly parsed if they have space characters
> * ideally some exception would bubble back up in the form of an ActionError
> Attached (in comments) is a simple controller and test case using HTMLUnit to
> demonstrate the issue. Even with the following logger settings, no errors
> are visible:
> {noformat}log4j.logger.org.apache.struts2=TRACE
> log4j.logger.com.opensymphony.xwork2=TRACE
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
