Skip to content

Composing synthetic converters from concrete converters [SPR-5794] #10464

Closed
@spring-projects-issues

Description

@spring-projects-issues

Oleg Zhurakousky opened SPR-5794 and commented

Here is the summary of the design as well as the list of core features
I am proposing with this implementation: (Patches are attached)

  • Similar to the DefaultTypeConverter I've implemented
    ComposingConverterService which extends GenericTypeConverter
  • ComposingConverterService provides all the functionality of the
    DefaultTypeConverter as well as ability (as it is also implementation
    of the ConverterRegistry) to have synthetic Converters composed from
    the set of concrete Converters. For example: Providing two concrete
    converters AtoB and BtoC the resulting converter map will actually
    have 3 converters AtoB, BtoC and AtoC (synthetic converter composed
    from sequential chain of AtoB and BtoC)
  • Prevents the creation of circular synthetic converters. For example:
    Having AtoB BtoC and CtoA could result in the creation of synthetic
    converter AtoA (via AtoB->BtoC->CtoA). Special hook is implemented to
    prevent this from happening and test was created to verify it.
  • Calculation of the most optimal routes for composition of the
    synthetic converters. For example: Let's say you have AtoB, BtoC, CtoD
    and BtoD concrete converters. This could result in two strategies for
    synthetic converter AtoD. One strategy would be composed via (AtoB,
    BtoC, CtoD) while another strategy would use different and more
    optimal route (AtoB and BtoD). Special hook is implemented to pick the
    latest conversion strategy as the most optimal one. Also, these
    conversion routes are recalculated and optimized in real time as new
    concrete converters are registered and could result in potential for
    more optimal route. Appropriate test cases were created to verify it.
  • Synthetic converters are created during initialization of the
    Converter service so during the usage phase no search and/or
    calculation is needed to find the appropriate conversion strategy as
    it is implemented in other frameworks (e.g., Tapestry) which i believe will affect (in a good
    way) a performance and quality of the conversion routines.
  • and other minor features

I have tested this service vs all the existing test cases as well as created
an additional test case and had a green bar across the screen.


Affects: 3.0 RC3

Attachments:

Issue Links:

1 votes, 4 watchers

Metadata

Metadata

Assignees

Labels

in: coreIssues in core modules (aop, beans, core, context, expression)status: declinedA suggestion or change that we don't feel we should currently applytype: enhancementA general enhancement

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions