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

Backport "MutablePropertySources#get throws when it should return null" [SPR-9185] #13823

Closed
spring-projects-issues opened this issue Feb 29, 2012 · 1 comment
Labels
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Feb 29, 2012

Chris Beams opened SPR-9185 and commented


This issue is a backport sub-task of #13817

Referenced from: commits 7d72ab5

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Feb 29, 2012

Chris Beams commented

commit 7d72ab59ae1841fecb0f33c938b37234dde75a8f
Author: Chris Beams <cbeams@vmware.com>
Date:   Wed Feb 29 14:29:13 2012 +0100

    Return null correctly from MutablePropertySources#get
    
    Prior to this commit, MutablePropertySources#get(String) would throw
    IndexArrayOutOfBoundsException if the named property source does not
    actually exist. This is a violation of the PropertySource#get contract
    as described in its Javadoc.
    
    The implementation now correctly checks for the existence of the named
    property source, returning null if non-existent and otherwise returning
    the associated PropertySource.
    
    Other changes
    
     - Rename PropertySourcesTests => MutablePropertySourcesTests
     - Polish MutablePropertySourcesTests for style, formatting
     - Refactor MutablePropertySources for consistency
    
    Issue: SPR-9185
    Backport-Issue: SPR-9179
    Backport-Commit: 15d1d824b54b2ec36a7c926e12644b391b310930

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant