Spring 6.2 is apparently planning to deprecate the ability to override beans by ID based on order of definition, so we’ll need to adapt some older cases in the configuration where that was a common trick used.
Many cases will hopefully devolve easily into a conditional pattern of testing for ID and then injecting DefaultID, but there will be some trickier cases and probably some breakage for deployers.
Environment
None
Activity
Ian Young
April 30, 2024 at 12:53 PM
In 6.1, they introduced BeanDefinitionRegistry.isBeanDefinitionOverridable as a default method on the interface (default true). Interestingly that's on a per-bean basis. I’m not sure whether what they are trying to do (when they change the default for this) is make some sort of mechanism by which we could explicitly permit overriding of selected cases that were important to us, while in transition.
At the DefaultListableBeanFactory level there has been is/set AllowBeanDefinitionOverriding since v4. I think this might be something we could set false (as I think Spring Boot has done since 2.1) to provoke this “no overrides” behaviour to see how it might affect us in advance before they start changing things.
Spring 6.2 is apparently planning to deprecate the ability to override beans by ID based on order of definition, so we’ll need to adapt some older cases in the configuration where that was a common trick used.
Many cases will hopefully devolve easily into a conditional pattern of testing for ID and then injecting DefaultID, but there will be some trickier cases and probably some breakage for deployers.