Skip to content

Clarify behavior for generics support in BeanUtils.copyProperties #27259

Closed
Closed
Clarify behavior for generics support in BeanUtils.copyProperties#27259
Assignees
sbrannen
Labels
in: coreIssues in core modules (aop, beans, core, context, expression)type: documentationA documentation task
Milestone
5.3.17

Description

@afattahi54
afattahi54
opened on Aug 11, 2021

The below code works in 5.2.9.RELEASE

BeanUtils.copyProperties(transferVO , transferRequest);

The classes where as follow. As you can see the source and destination beans has a List with same name but different types. But it was working

public class transferVO {
	private List<Signer> signers;
}

public class transferRequest{	
	private List<TransferSigners > signers;

}


public class Signer{
    private string name;

}

public class TransferSigners {    
    private string name;
}

After upgrade to 5.3.7 the signers property is not copied.

Activity

  1. spring-projects-issues
    added
    status: waiting-for-triageAn issue we've not yet triaged or decided on
    on Aug 11, 2021
  2. sbrannen
    added
    in: coreIssues in core modules (aop, beans, core, context, expression)
    on Aug 12, 2021

  3. sbrannen commented on Aug 12, 2021

    @sbrannen
    sbrannen
    on Aug 12, 2021
    Member

    This is a potential regression introduced in conjunction with #24187.

    @afattahi54, can you please also provide the setter and getter methods of those two classes so that we can inspect the actual method signatures?

    Also, if Signer is not a subtype of TransferSigners, why would you expect BeanUtils to copy from List<Signer> to List<TransferSigners>?

    Doing so would actually store items in the List<TransferSigners> that are not an instance of TransferSigners, and that would be a broken state.

  4. sbrannen
    added
    status: waiting-for-feedbackWe need additional information before we can continue
    on Aug 12, 2021

  5. afattahi54 commented on Aug 14, 2021

    @afattahi54
    afattahi54
    on Aug 14, 2021
    Author

    The Signer and TransferSigners do not have same types. You are right, but as it was working before upgrade to 5.3.7 I expected it to keep working

    The setters and getters are as below:

    public class transferVO {
        private List<Signer> signers;
	public List<Signer> getSigners() {
		return signers;
	}

	public void setSigners(List<Signer> signers) {
		this.signers = signers;
	}

}

public class transferRequest {

       private List<TransferSigners > signers;
	public List<TransferSigners> getSigners() {
		return signers;
	}
	public void setSigners(List<TransferSigners> signers) {
		this.signers = signers;
	}

}

    Thanks

  6. spring-projects-issues
    added
    status: feedback-providedFeedback has been provided
    and removed
    status: waiting-for-feedbackWe need additional information before we can continue
    on Aug 14, 2021

  7. bigdata-page commented on Nov 24, 2021

    @bigdata-page
    bigdata-page
    on Nov 24, 2021

    This is a potential regression introduced in conjunction with #24187.

    @afattahi54, can you please also provide the setter and getter methods of those two classes so that we can inspect the actual method signatures?

    Also, if Signer is not a subtype of TransferSigners, why would you expect BeanUtils to copy from List<Signer> to List<TransferSigners>?

    Doing so would actually store items in the List<TransferSigners> that are not an instance of TransferSigners, and that would be a broken state.

    @sbrannen spring-beans version is 5.3.9, when Signer is a subtype of TransferSigners，use the BeanUtils.copyProperties(transferVO , transferRequest). the transferVO.signers is null. but when spring-beans version is 5.1.16.RELEASE is normal. I hope the new version is compatible with the previous version.

  8. sbrannen
    added this to the Triage Queue milestone on Nov 29, 2021

  9. sbrannen commented on Nov 29, 2021

    @sbrannen
    sbrannen
    on Nov 29, 2021
    Member

    Assigned to the Triage Queue so that the team can determine if this is a regression that needs to be fixed.

  10. rstoyanchev
    added
    type: regressionA bug that is also a regression
    on Nov 29, 2021
  11. snicoll
    removed
    status: waiting-for-triageAn issue we've not yet triaged or decided on
    status: feedback-providedFeedback has been provided
    on Nov 29, 2021
  12. snicoll
    modified the milestones: Triage Queue, 5.3.14 on Nov 29, 2021
  13. sbrannen
    self-assigned this
    on Dec 13, 2021
  14. sbrannen
    added
    type: documentationA documentation task
    and removed
    type: regressionA bug that is also a regression
    on Dec 13, 2021
  15. jhoeller
    modified the milestones: 5.3.14, 5.3.15 on Dec 14, 2021
  16. sbrannen
    modified the milestones: 5.3.15, 5.3.16 on Jan 12, 2022
  17. sbrannen
    modified the milestones: 5.3.16, 5.3.17 on Feb 16, 2022
  18. sbrannen
    changed the title [-]BeanUtils.copyProperties breaks from 5.2.9.RELEASE to 5.3.7[/-] [+]Clarify behavior for generics support in BeanUtils.copyProperties[/+] on Mar 12, 2022
  19. sbrannen
    added a commit that references this issue on Mar 12, 2022

    Clarify behavior for generics support in BeanUtils.copyProperties()

    887389d
  20. sbrannen
    closed this as completedin 887389don Mar 12, 2022

  21. sbrannen commented on Mar 12, 2022

    @sbrannen
    sbrannen
    on Mar 12, 2022
    Member

    The Signer and TransferSigners do not have same types. You are right, but as it was working before upgrade to 5.3.7 I expected it to keep working

    @afattahi54, since BeanUtils.copyProperties() honors generics since Spring Framework 5.3, you will need to ensure that the source and target property types are compatible in terms of Java semantics.

    spring-beans version is 5.3.9, when Signer is a subtype of TransferSigners，use the BeanUtils.copyProperties(transferVO , transferRequest). the transferVO.signers is null. but when spring-beans version is 5.1.16.RELEASE is normal. I hope the new version is compatible with the previous version.

    @bigdata-page, that can be addressed by using an upper-bounded wildcard for the target property type.

    In commit 887389d, I added a table to the Javadoc for BeanUtils.copyProperties() which will hopefully help you and other users better understand the current semantics for property type matching.

    BeanUtils copyProperties

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

in: coreIssues in core modules (aop, beans, core, context, expression)type: documentationA documentation task

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions