Skip to content

Printer<T> are not autoconfigured when exposed as a bean #16171

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
tloist opened this issue Mar 8, 2019 · 1 comment
Closed

Printer<T> are not autoconfigured when exposed as a bean #16171

tloist opened this issue Mar 8, 2019 · 1 comment
Labels
status: superseded An issue that has been superseded by another

Comments

@tloist
Copy link

tloist commented Mar 8, 2019

Status Quo

The WebMvcAutoConfiguration auto detects beans of type:

  • Converter
  • GenericConverter
  • Formatter

and automatically registers them for the ConversionService. Formatters are in fact only a combination of Printer and Parser. For each Formatter, the formatter is split into these two parts and registered as two serperate conversion services again.
My suggestion is:

  • Scanning for Parser and Printer seperately, which means the above list changes to:

    • Converter
    • GenericConverter
    • Printer
    • Parser

    If this introduces performance problems, an alternative would be to:

  • Scan for Printer instead, then for each Printer check if the Printer is also a Parser (and thus a Formatter) and register the second conversion service as well. Which would make that list from above into:

    • Converter
    • GenericConverter
    • Printer
      • Parser

Intended advantages

What this would make possible is to have a Printer without a Parser auto registered in the conversion service if exposed as a bean. This is useful for those cases, where you want to represent an object on the UI (e.g. templating in thymeleaf with ${{MyClass}}) but never read it from a String.

If you tend to my 2nd proposal, this leaves the question: Why only checking for a Parser in case it is already a Printer?

2 reasons:

  • Compability: Currently Formatter also register conversions String -> MyClass and not doing it, would break these applications relying on this behaviour.
  • On the other hand I can't really think of a lot of use cases where registering a Parser without a Printer is realistic. If you know a String representation for MyClass that you can read, what should be the reason, you can't also write it?

Workaround

Currently Printer which are not also Formatter are not registered in the conversion service. Either:

  • configure them manually / programmatically with an WebMvcConfigurer or
  • just convert them to be a Formatter and throw an Exception for reading them from a String. That turns this case into a runtime exception.
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Mar 8, 2019
@philwebb philwebb added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged labels Apr 9, 2019
@philwebb philwebb added this to the 2.2.x milestone Apr 9, 2019
nosan added a commit to nosan/spring-boot that referenced this issue Jun 5, 2019
nosan added a commit to nosan/spring-boot that referenced this issue Jun 5, 2019
nosan added a commit to nosan/spring-boot that referenced this issue Jun 8, 2019
nosan added a commit to nosan/spring-boot that referenced this issue Jun 8, 2019
nosan added a commit to nosan/spring-boot that referenced this issue Jun 10, 2019
@philwebb
Copy link
Member

Closing in favor of PR #17064

@philwebb philwebb removed this from the 2.2.x milestone Jun 10, 2019
@philwebb philwebb added status: superseded An issue that has been superseded by another and removed type: enhancement A general enhancement labels Jun 10, 2019
nosan added a commit to nosan/spring-boot that referenced this issue Jun 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: superseded An issue that has been superseded by another
Projects
None yet
Development

No branches or pull requests

3 participants