Lukasz Lenart created WW-5673:
---------------------------------
Summary: 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
Reporter: Lukasz Lenart
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)
