Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AbstractBeanDefinition#equals handles propertyValues incorrectly #26433

Closed
AnthonyYeracaris opened this issue Jan 22, 2021 · 2 comments
Closed
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: backported An issue that has been backported to maintenance branches type: regression A bug that is also a regression
Milestone

Comments

@AnthonyYeracaris
Copy link

See line 1198: ObjectUtils.nullSafeEquals(this.propertyValues, that.propertyValues)
Look at AbstractBeanDefinition#getPropertyValues, line 891, which treats, in effect a propertyValues of null as equivalent to en empty MutablePropertyValues object (i.e., a side-effect of getPropertyValues is to create an empty MutablePropertyValues object when propertyValues is null).
Affects version 5.3.3

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jan 22, 2021
@jhoeller jhoeller self-assigned this Jan 23, 2021
@jhoeller jhoeller added in: core Issues in core modules (aop, beans, core, context, expression) type: bug A general bug and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jan 23, 2021
@jhoeller jhoeller added this to the 5.3.4 milestone Jan 23, 2021
@jhoeller jhoeller added type: regression A bug that is also a regression and removed type: bug A general bug labels Jan 23, 2021
@jhoeller
Copy link
Contributor

jhoeller commented Jan 23, 2021

This turns out to be a regression from 4.3.x where there always were empty MutablePropertyValues and ConstructorArgumentValues instances in every BeanDefinition. In 5.x we optimized those to be lazily created but accidentally consider BeanDefinition instances non-equal now if they are not in the same field initialization state, even if nothing has been registered.

@AnthonyYeracaris
Copy link
Author

BTW, and forgive me if it's too obvious, but don't forget the hashCode() implementation.

jhoeller added a commit that referenced this issue Feb 14, 2021
This was referenced Mar 13, 2021
lxbzmy pushed a commit to lxbzmy/spring-framework that referenced this issue Mar 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: backported An issue that has been backported to maintenance branches type: regression A bug that is also a regression
Projects
None yet
Development

No branches or pull requests

3 participants