[
https://issues.apache.org/jira/browse/WW-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated WW-5673:
------------------------------
Component/s: Core
> Remove the deprecated ConversionRule.COLLECTION and Collection_ prefix
> constants
> --------------------------------------------------------------------------------
>
> Key: WW-5673
> URL: https://issues.apache.org/jira/browse/WW-5673
> Project: Struts 2
> Issue Type: Improvement
> Components: Core
> Reporter: Lukasz Lenart
> Priority: Minor
> Fix For: 8.0.0
>
>
> Follow-up to WW-5656, which annotated these as {{@Deprecated(since =
> "7.3.0")}} without {{forRemoval}}. Removing them is source-breaking for
> applications, so it belongs in a major release.
> h2. Scope
> ||Item||Action||
> |{{ConversionRule.COLLECTION}}|remove the enum constant|
> |{{ConversionRule.prefix()}}|drop the {{case COLLECTION ->}} arm and the
> {{@SuppressWarnings("deprecation")}}|
> |{{DefaultObjectTypeDeterminer.DEPRECATED_ELEMENT_PREFIX}}|remove the
> constant|
> |{{XWorkConverter.CONVERSION_COLLECTION_PREFIX}}|remove the constant (a
> second public spelling of the same literal, never read by the framework)|
> |{{DefaultConversionAnnotationProcessor.process(...)}}|drop the
> {{ConversionRule.COLLECTION}} term from the guard and the suppression|
> |Test fixtures {{AnnotationUser}}, {{ConversionTestAction}}|migrate {{rule =
> COLLECTION}} to {{ELEMENT}}|
> |{{ConversionRuleTest}}, {{XWorkConverterTest}}|drop the {{Collection_}}
> assertions covering the removed constant|
> h2. Open decision: the properties-file fallback
> Removing the *Java constants* and removing the *{{Collection_}} key fallback
> in {{-conversion.properties}} files* are two independent decisions, and this
> ticket should settle both.
> {{DefaultObjectTypeDeterminer.getElementClass(...)}} reads
> {{Element_${property}}} first and falls back to {{Collection_${property}}},
> logging an INFO when the fallback is hit. That fallback is what keeps
> long-lived {{-conversion.properties}} files working, and it costs almost
> nothing to keep — it can survive the removal of the enum constant by inlining
> the literal.
> Two options:
> # *Remove the constants, keep the fallback.* The conservative choice.
> Applications with {{Collection_xxx}} entries in their conversion properties
> keep working; only code written against the Java API breaks. The literal
> {{"Collection_"}} gets inlined into {{getElementClass}} with a comment.
> # *Remove both.* A cleaner engine, but it silently changes behaviour for any
> application still shipping {{Collection_xxx}} properties: the element type
> stops being resolved and conversion falls through to generic parametrics. If
> this option is taken it needs a prominent migration note, and arguably a WARN
> rather than the current INFO in the 7.x line first.
> Note that these test resources still exercise the fallback and would have to
> be migrated under option 2:
> {{core/src/test/resources/org/apache/struts2/test/User-conversion.properties}},
> {{.../util/Cat-conversion.properties}},
> {{.../util/Tiger-conversion.properties}}, plus the {{Collection_list}}
> lookups in {{XWorkConverterTest}}.
> h2. Background
> {{Collection_}} and {{Element_}} express the same thing: the element type
> inside a collection. {{Element_}} additionally covers the *values* of a
> {{Map}}, which is why WebWork 2.1 introduced it as the single name for both
> cases and kept {{Collection_}} as a fallback. The two have been
> interchangeable in the engine ever since, and the deprecation has been stated
> in prose since 2.1.x — WW-5656 only made it machine-visible.
> Also worth updating on removal: the {{DefaultObjectTypeDeterminer}} class
> Javadoc, which still says the {{Collection_xxx}} format "is still supported
> and honored, although it is deprecated and will be removed eventually".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
