You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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.
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.
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.
Juergen Hoeller opened SPR-16791 and commented
SnakeYAML breaks our
StrictMapAppenderConstructor
by using a differentcreateDefaultMap()
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 callingMap.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 pointlessStrictMapAppenderConstructor
(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:
The text was updated successfully, but these errors were encountered: