Restore YamlProcessor duplicate key handling against SnakeYAML 1.18+ (plus compatibility with 1.21) [SPR-16791]

[spring-projects-issues]

Juergen Hoeller opened SPR-16791 and commented

SnakeYAML breaks our StrictMapAppenderConstructor by using a different createDefaultMap() signature as of SnakeYAML 1.21. It turns out that beyond this current issue, duplicate key detection is broken for SnakeYAML 1.18+ since the YAML parser has some duplicate key handling built in now, never calling Map.put a second time and therefore bypassing our check on the decorated map.

Let's upgrade to SnakeYAML's new policy as of Spring Framework 5.0.6, using LoaderOptions.setAllowDuplicateKeys(false), deprecating our now pointless StrictMapAppenderConstructor (and removing it altogether for 5.1). Stéphane Nicoll, Andy Wilkinson, this might affect Boot as well (remembering #18082).

---

Affects: 5.0.5

Issue Links:

• YamlProcessor subclasses can no longer instantiate StrictMapAppenderConstructor [SPR-13504] #18082 YamlProcessor subclasses can no longer instantiate StrictMapAppenderConstructor
• YamlPropertiesFactoryBean loses entries in the YAML document that have an empty array value [SPR-16769] #21310 YamlPropertiesFactoryBean loses entries in the YAML document that have an empty array value

[spring-projects-issues]

Juergen Hoeller commented

Stéphane Nicoll, Andy Wilkinson, since duplicate key detection is effectively broken against SnakeYAML 1.18 (which is out for more than a year already), we could also consider backporting this revision to 5.0.6 and therefore Boot 2.0.2, just leaving StrictMapAppenderConstructor in place in deprecated form there (while it'll be gone in 5.1) . The only real downside is a requirement for SnakeYAML 1.18+ in the 5.0.x line then... but that might not affect many people at this point, in particular not within Boot.

[spring-projects-issues]

Andy Wilkinson commented

Thanks, Juergen. In Boot 2.0, things have moved on a bit since #18082. We now only use StrictMapAppenderConstructor by sub-classing it (1.5 continues to instantiate it directly). That sub-classing is only done in a private inner class so it should be straightforward for us to move away from it when it's deprecated/removed. As for a SnakeYAML 1.18+ requirement, that's also fine from a Boot perspective as 2.0.x uses 1.19.

[spring-projects-issues]

Juergen Hoeller commented

Andy Wilkinson, Boot is fine with the latest 5.0.6 snapshot so far? I'm mostly concerned about side effects... after all, we're asking SnakeYAML to disallow duplicate keys at its parser level now, possibly rejecting a few (invalid) things that we couldn't detect before.

[spring-projects-issues]

Stéphane Nicoll commented

Juergen Hoeller we've adapted to the new API as of 2.0.2.BUILD-SNAPSHOT (see this commit). CI is green