3.0.6 Map to Map conversion shallow copying maps causing unexpected results on upgrade from 3.0.5 [SPR-8714]

[spring-projects-issues]

Ricardo Gladwell opened SPR-8714 and commented

We have created a AbstractMap sub-class, SoftExpireHashMap. This has configurable behaviour which is achieved by setting properties. Once the SoftExpireHashMap has been configured, it must have the init() method called on it so that it can start a thread executor which runs in the background periodically pruning expired cached items.

However, using the default converters included with the 3.0.6 version of org.springframework.format.support.FormattingConversionServiceFactoryBean we find that this Map is being shallow copied before being injected into our objects and is, hence, not initialised.

Please see the following test case that replicates this issue:

https://github.com/rgladwell/spring-map-converter-issue

For some reason the MapToMapConverter is copying this Map despite the fact we don't want any conversions carried out on it.

Workaround: We can eliminate this behaviour by calling FormatterRegistry.removeConvertible(Map.class, Map.class) but obviously this is problem if we ever do need Map to Map conversion.

---

Affects: 3.0.6

Issue Links:

• Collection Binding broken - TypeConverterDelegate does bind Collection Elements to Collection type instead of the collection elements Type [SPR-8674] #13316 Collection Binding broken - TypeConverterDelegate does bind Collection Elements to Collection type instead of the collection elements Type
• SpEL: Unnecessary conversion of Map<?, ?> arguments [SPR-8518] #13163 SpEL: Unnecessary conversion of Map arguments

Referenced from: commits c9607fd, cb5954e

1 votes, 2 watchers

[spring-projects-issues]

Keith Donald commented

Ricardo,
Can you provide a bit more information on your scenario. What is the type of property you are binding to (e.g. the setter method argument type). Is it a Map, or a SoftExpireHashMap? Who do you expect to call the init method on your SoftExpireHashMap, the container? Just to clarify, you expect your container-initialized SoftExpireHashMap instance to be set as a property on a Spring-managed bean as-is, with no copy created, correct?

[spring-projects-issues]

Ricardo Gladwell commented

Hi Keith

We are binding to the concrete type (SoftExpireHashMap) in the setter method argument. The API we are using expects the consumer of the SoftExpireHashMap (the TreeMapConsumer in the attached test case) to initialise the SoftExpireHashMap.

So, as you say, we expect the SoftExpireHashMap instance to be set as a property on a Spring-managed bean as-is, with no copy created.

[spring-projects-issues]

Rossen Stoyanchev commented

A fix has been made to check if a copy of the source map is required. This is the case either if the source map is not assignable to the target map type or if any map keys/values actually undergo type conversion. If none of these are true the original source map is returned.

Validating the fix in your code would be great!

[spring-projects-issues]

Ricardo Gladwell commented

Is there a Maven repo from which I can obtain Spring 3.1 RC1? I can't seem to download it from:

http://maven.springframework.org/milestone

[spring-projects-issues]

Rossen Stoyanchev commented

RC1 should become available soon. In the mean time use the latest snapshot build:

Version => 3.1.0.BUILD-SNAPSHOT
Maven repository => http://maven.springframework.org/snapshot

[spring-projects-issues]

Ricardo Gladwell commented

Thanks I can verify this works for Spring 3.1 snapshot.

[spring-projects-issues]

Juergen Hoeller commented

Backported to 3.0.7, for release in late December.

Juergen