spring-projects / spring-projects/spring-security
Consider favoring ObjectProvider#getIfAvailable
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 9.6k
- Forks
- 6.3k
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 52
Description
Given #15816, it may be easier to make Spring Security's bean resolution policy more consistent.
Reports like #15751 and #15538 make it clear that the existing behavior in some parts of Spring Security is surprising. To alleviate that, we can favor ObjectProvider#getIfAvailable. This is already an improvement over getBeanOrNull since it also supports the @Primary annotation, simplifying the remediation for duplicate beans.
Because getIfAvailable throws an exception when there are multiple candidate beans and getIfUnique does not, this is not a passive change, so it would need to happen in Spring Security 7 or later.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing #15816, #15751, and #15538, then locate Spring Security bean-resolution paths that use getBeanOrNull or equivalent lookups. The work is done when the relevant policy favors ObjectProvider#getIfAvailable in Spring Security 7 or later and duplicate-bean behavior, including @Primary handling, is covered.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, spring
- Domain
- backend, security
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100