The default MessageConverters are initialized in constructor of RestTemplate. This solution has some problems:
When I want different set of MessageConverters, the default MessageConverters are initialized first and than replaced by setMessageConverters(..) method. This slows down the application startup.
When I have some classes as JAXB, Jackson on classpath, than some other default converters are initialized too (but I don't use these technologies (JAXB, Jackson) with RestTempate) - this slows down the startup, so I want to specify my "limited" set of Converters - but is the same problem as 1).
When I have 2 WAR applications in Tomcat, and one application sets the System property "javax.xml.transform.TransformerFactory" for Xalan XSLTC, and the second application does not have Xalan on classpath and does not use the XSLT,but instantiates RestTemplate for JSON based communication, than Exception is thrown:
I don´t want to initialize any default XML message Converter for RestTemplate, because I use only JSON for communication -> I want to configure my own set of MessageConverters, but the constructor is called first and destroyed by the exception.
So please, move the initialization of default MessageConvertors for RestTemplate from constructor to some @PostConstruct method, and initialize these default converters only in situations, when the Array of converters was not set (preinitialized) by setMessageConventers(...) operation from configuration.
Affects: 3.2.4, 4.0 GA
#16578 Backward compatibility issue in RestTemplate's messageConverters after SPR-11351
Just so you are aware, Spring Boot provides an HttpMessageConverters convenience @Bean which you can use to grab a global list of message converters to initialize your RestTemplate and MVC stuff. We could copy that in Spring and make the user install that bean himself, I guess. Or we could recommend the use of Spring Boot (probably better for everyone).
The RestTemplate can be instantiated directly, not necessarily through Spring configuration so @PostContruct callbacks won't apply there. We could introduce additional constructors accepting a list of converters. Arjen Poutsma, any other suggestions?