Spring context reloads failing on parent beans property type conversions
Basics
Logistics
Basics
Logistics
Description
There's some kind of Spring bug that manifests by failing to properly track the state of bean properties internally when there are property type conversions involved (which is most of the time of course).
When a parent bean is used to define new child beans in two different reloadable service contexts (e.g. the filter and resolver, doesn't matter which ones), things seem to work. But if one of the service contexts directly references a parent bean to inject it into something else, that seems to corrupt the state of the parent bean.
A later reload of the other context with the child bean in it fails because it ends up with unconverted property values pulled in from the parent bean but without the properties marked as needing conversion, and it causes Spring to attempt to set the property values without converting them, and you get type mismatch errors.
Environment
None
Activity
Scott CantorAugust 21, 2019 at 7:06 PM
I spent a fairly involved debugger session tracing the Spring logic, and I have a vague idea what's happening and definitely am far enough to know it's a Spring bug, but I'm not sure I could characterize it well enough to file a bug with them that they'd "get".
It has to do with how Spring tracks the original and converted values and how it in parallel tracks whether "conversion is needed", and it ends up out of sync. It converts the value, but leaves the property in the child in a state where the conversion was done but it's marked as "not needing conversion", so the eventual setter logic tries to set the original value and not the converted one.
There's some kind of Spring bug that manifests by failing to properly track the state of bean properties internally when there are property type conversions involved (which is most of the time of course).
When a parent bean is used to define new child beans in two different reloadable service contexts (e.g. the filter and resolver, doesn't matter which ones), things seem to work. But if one of the service contexts directly references a parent bean to inject it into something else, that seems to corrupt the state of the parent bean.
A later reload of the other context with the child bean in it fails because it ends up with unconverted property values pulled in from the parent bean but without the properties marked as needing conversion, and it causes Spring to attempt to set the property values without converting them, and you get type mismatch errors.