-
Notifications
You must be signed in to change notification settings - Fork 41.2k
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
Labels
status: superseded
An issue that has been superseded by another
Comments
nosan
added a commit
to nosan/spring-boot
that referenced
this issue
Jun 5, 2019
if they have been exposed as beans. see spring-projectsgh-16171
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
Closing in favor of PR #17064 |
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
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 ofPrinter
andParser
. For eachFormatter
, the formatter is split into these two parts and registered as two serperate conversion services again.My suggestion is:
Scanning for
Parser
andPrinter
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 eachPrinter
check if thePrinter
is also aParser
(and thus aFormatter
) 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 aParser
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 aString
.If you tend to my 2nd proposal, this leaves the question: Why only checking for a
Parser
in case it is already aPrinter
?2 reasons:
Formatter
also register conversionsString
->MyClass
and not doing it, would break these applications relying on this behaviour.Parser
without aPrinter
is realistic. If you know a String representation forMyClass
that you can read, what should be the reason, you can't also write it?Workaround
Currently
Printer
which are not alsoFormatter
are not registered in the conversion service. Either:WebMvcConfigurer
orFormatter
and throw an Exception for reading them from a String. That turns this case into a runtime exception.The text was updated successfully, but these errors were encountered: