Skip to content

Recently changes of GenericTypeAwarePropertyDescriptor breaks BeanUtils.copyProperties() [SPR-11209] #15834

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

Closed
spring-projects-issues opened this issue Dec 11, 2013 · 2 comments
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: bug A general bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

Marko Umek opened SPR-11209 and commented

In release 3.2.4 BeanUtils.copyProperties() ignores invalid property definirions like these:

public class InvalidBean {
    public String getValue() {...}
    public void setValue(int intValue) {...}
}

The culprit lies in class GenericTypeAwarePropertyDescriptor line 72, 73:

Method candidate = ClassUtils.getMethodIfAvailable(
	this.beanClass, "set" + StringUtils.capitalize(getName()), (Class<?>[]) null); // < Missing return type (!)
if (candidate != null && candidate.getParameterTypes().length == 1) {
	writeMethodToUse = candidate;
}

versus

writeMethodToUse = ClassUtils.getMethodIfAvailable(this.beanClass,
	"set" + StringUtils.capitalize(getName(), readMethodToUse.getReturnType());


Affects: 3.2.5

Referenced from: commits bc5affa, bfcfbe4

Backported to: 3.2.6

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Good catch! I made BeanUtils.copyProperties defensive about property type mismatches, since those are generally allowed these days (not least of it all due to recent JDK BeanInfo changes to that effect in JDK 8).

Juergen

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Dec 15, 2013

Chad Wilson commented

This change appears to have broken backwards compatibility for primitive <-> wrapper copying. Would appreciate any comment on #15856.

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: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants