[
https://issues.apache.org/jira/browse/WW-3871?focusedWorklogId=1032178&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1032178
]
ASF GitHub Bot logged work on WW-3871:
--------------------------------------
Author: ASF GitHub Bot
Created on: 25/Jul/26 16:46
Start Date: 25/Jul/26 16:46
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #1812:
URL: https://github.com/apache/struts/pull/1812
Fixes [WW-3871](https://issues.apache.org/jira/browse/WW-3871)
## What
`@TypeConversion` now derives its conversion-mapping key prefix from the
declared `ConversionRule`, so a bare property name works as `key` at class,
method and field level:
```java
// both forms are now equivalent
@TypeConversion(key = "annotatedBeanMap", rule =
ConversionRule.KEY_PROPERTY, value = "id")
@TypeConversion(key = "KeyProperty_annotatedBeanMap", rule =
ConversionRule.KEY_PROPERTY, value = "id")
```
Half of the reporter's request was already implemented in 2018 (77cbafb74),
which taught the *method-level* path to derive the key from the property name.
This closes the remaining gaps.
## Changes
- **`ConversionRule.prefix()`** owns the rule-to-prefix table, previously
duplicated inline. The `switch` is exhaustive with no `default`, so a future
rule cannot silently ship without a prefix.
- **`XWorkConverter.resolveKey(type, rule, name)`** is the single resolver
all annotation passes route through — explicit keys and derived property names
alike. A key that already carries a rule prefix is returned untouched, so
existing annotations keep working byte-for-byte. `ConversionType.APPLICATION`
keys are class names and are never prefixed.
- **`addConverterMapping` split into four ordered passes** — properties
file, class-level, method, field — keeping the existing first-writer-wins rule.
The previous single method was ~45 lines of nested loops.
- **`@TypeConversion` is now `@Target({METHOD, FIELD})`**, which its Javadoc
has always claimed. The field pass reads declared, non-static, non-synthetic
fields only; `buildConverterMapping` already walks the hierarchy.
Two defects in the same code path are fixed as a byproduct:
- `break` where `continue` was meant: one already-mapped key aborted the
**remaining** `@TypeConversion` entries in a `@Conversion` array.
- An empty class-level `key` registered a mapping under `""`. It is now
skipped with a WARN naming the class.
## Compatibility
Source- and binary-compatible. `MyBeanAction` deliberately keeps its
spelled-out prefixes and its tests are untouched — that is the
backward-compatibility evidence, alongside a new bare-key twin asserted to
produce an identical mapping.
The one behavioural change to existing code: an explicit method-level key
carrying a non-`PROPERTY` rule without its prefix now resolves to the prefixed
key. That mapping was unreachable before, so this turns a silent no-op into the
behaviour the author intended.
## Notes for review
- The "already prefixed" guard matches against **every** rule's prefix, not
just the declared rule's. `COLLECTION` and `ELEMENT` are interchangeable —
`DefaultConversionAnnotationProcessor` handles both in one branch and
`DefaultObjectTypeDeterminer.getElementClass` reads `Element_` then falls back
to the deprecated `Collection_` — so `key = "Element_users", rule = COLLECTION`
must not become `Collection_Element_users`.
- Precedence is class > method > field per class. Because the method pass
reads `getMethods()` (inherited) while the field pass reads
`getDeclaredFields()`, a superclass's annotated setter beats a subclass's field
annotation; this is documented on `processFieldAnnotations`.
- Out of scope, but noticed: `DefaultConversionFileProcessor:69` has the
identical `break`-instead-of-`continue` defect for `-conversion.properties`
files. Happy to file a follow-up.
## Testing
`mvn test -DskipAssembly -pl core` — 3040/3040 passing. `mvn javadoc:javadoc
-pl core` clean.
New coverage: `ConversionRuleTest`; `resolveKey` unit tests including prefix
crossover and the `APPLICATION` carve-out; class-level bare keys asserted equal
to the spelled-out form; a `-conversion.properties` key collision proving later
entries still register; field derivation and method-over-field precedence; and
an end-to-end binding test through the action lifecycle.
Design notes and the implementation plan are included under
`docs/superpowers/`.
Issue Time Tracking
-------------------
Worklog Id: (was: 1032178)
Remaining Estimate: 0h
Time Spent: 10m
> TypeConversion annotation support improvement
> ---------------------------------------------
>
> Key: WW-3871
> URL: https://issues.apache.org/jira/browse/WW-3871
> Project: Struts 2
> Issue Type: Improvement
> Components: Plugin - Convention
> Affects Versions: 2.3.4.1
> Reporter: Pavan Ananth
> Assignee: Lukasz Lenart
> Priority: Major
> Fix For: 7.3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The annotation support for TypeConversion in Struts 2 is too literal an
> interpretation of the XML support. For instance, I am required to supply this
> if I have choose the CreateIfNull feature at a property level :
> @TypeConversion(key="CreateIfNull_users", rule=ConversionRule.CreateIfNull,
> value="true")
> List<User> users;
> Given that the rule is CreateIfNull, the key can be constructed implicitly
> using property name - why is it asked of an user to type in the full key.
> This holds good for the other supported ConversionRules as well
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
