Description
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
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 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 conversionsString
->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 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 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.