Backward compatibility issue in RestTemplate's messageConverters after SPR-11351 [SPR-11962]

[spring-projects-issues]

Boaz opened SPR-11962 and commented

Hi,

We've recently upgraded our Spring version from 3.2.6 to 3.2.9 and we've encountered a backwards compatibility issue.
Usually we use RestTemplate with it's default set of messageConverters, but in some places we add custom message converters to the existing collection of message converters, it looks as follows:

RestTemplate restTemplate = new RestTemplate();
List<HttpMessageConverter<?>> converters = restTemplate.getMessageConverters();
converters.add(new SomeCustomMadeConverter());
restTemplate.setMessageConverters(converters);

In version 3.2.9 (after merging the fix for #15976in commit 425e5a0) the setMessageConverters method changed from this:

this.messageConverters = messageConverters;

to this:

this.messageConverters.clear();
this.messageConverters.addAll(messageConverters);

Causing us to loose all the converters instead of adding one and, of course -

IllegalArgumentException: 'messageConverters' must not be empty

We did an innocent mistake and expected to get from the getMessageConverters method a copy of the list (and not have a reference to the inner works of the RestTemplate) without consulting the source code.
It's clear that other developers might have directly added to that list without calling setMessageConverters afterwards, so some flows won't be backward compatible. But I do think that returning a copy of a list in getMessageConverters is better then returning the list itself, especially since spring does this.messageConverters.clear(); in the set.

---

Affects: 3.2.9, 4.0.5

Issue Links:

• Provide alternative RestTemplate constructor to avoid default MessageConverter creation [SPR-11351] #15976 Provide alternative RestTemplate constructor to avoid default MessageConverter creation

Referenced from: commits 60d3a7f, a45d49c, 1222ca3

Backported to: 3.2.10

[spring-projects-issues]

Juergen Hoeller commented

RestTemplate accepts the getMessageConverters() List on setMessageConverters again, simply by checking whether the incoming List reference is identical to the internal one. That should restore backwards compatibility with all previously working scenarios.

Juergen

[spring-projects-issues]

Boaz commented

You're right of course, thanks for the quick fix!