-
Notifications
You must be signed in to change notification settings - Fork 41.7k
Description
Status Quo
The WebMvcAutoConfiguration auto detects beans of type:
ConverterGenericConverterFormatter
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
ParserandPrinterseperately, which means the above list changes to:ConverterGenericConverterPrinterParser
If this introduces performance problems, an alternative would be to:
-
Scan for
Printerinstead, then for eachPrintercheck if thePrinteris also aParser(and thus aFormatter) and register the second conversion service as well. Which would make that list from above into:ConverterGenericConverterPrinterParser
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
Formatteralso register conversionsString->MyClassand 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
Parserwithout aPrinteris realistic. If you know a String representation forMyClassthat 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
WebMvcConfigureror - just convert them to be a
Formatterand throw an Exception for reading them from a String. That turns this case into a runtime exception.