Skip to content

Treat the only one default candidate as effectively primary #1

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.

Sign up for GitHub

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

Jump to bottom
Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Treat the only one default candidate as effectively primary #1

wants to merge 1 commit into from

Conversation

@Pankraz76
Copy link
Owner

@Pankraz76 Pankraz76 commented Feb 17, 2025

@Pankraz76
Copy link
Owner Author

Pankraz76 commented Feb 17, 2025

nice approach looks perfectly fine to me.

Pankraz76
Pankraz76 commented Feb 17, 2025
View reviewed changes
Copy link
Owner Author

@Pankraz76 Pankraz76 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well done

...eans/src/main/java/org/springframework/beans/factory/support/DefaultListableBeanFactory.java
}
}
}
return candidateBeanName;
Copy link
Owner Author

@Pankraz76 Pankraz76 Feb 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe filtering would highlight the main condition:

.filter(entry -> entry.getValue().isAutowireCandidate() && entry.getValue().isDefaultCandidate())

protected String determineEffectivelyPrimaryCandidate(Map<String, Object> candidates, Class<?> requiredType) {
    return candidates.entrySet().stream()
        .map(entry -> Map.entry(entry.getKey(), transformedBeanName(entry.getKey())))
        .filter(entry -> containsBeanDefinition(entry.getValue()))
        .map(entry -> Map.entry(entry.getKey(), getMergedLocalBeanDefinition(entry.getValue())))
        .filter(entry -> entry.getValue().isAutowireCandidate() && entry.getValue().isDefaultCandidate())
        .map(Map.Entry::getKey)
        .reduce((a, b) -> null) // Ensures only one candidate; otherwise, null
        .orElse(null);
}

Its although nice, if a method has only has one return statement.

Pankraz76 pushed a commit that referenced this pull request Nov 11, 2025
@sbrannen
Support JUnit Jupiter ExtensionContextScope.TEST_METHOD
d24a31d 
Historically, @⁠Autowired fields in an enclosing class of a @⁠Nested
test class have been injected from the ApplicationContext for the
enclosing class. If the enclosing test class and @⁠Nested test class
share the same ApplicationContext configuration, things work as
developers expect. However, if the enclosing class and @⁠Nested test
class have different ApplicationContexts, that can lead to
difficult-to-debug scenarios. For example, a bean injected into the
enclosing test class will not participate in a test-managed transaction
in the @⁠Nested test class (see spring-projectsgh-34576).

JUnit Jupiter 5.12 introduced a new ExtensionContextScope feature which
allows the SpringExtension to behave the same for @⁠Autowired fields as
it already does for @⁠Autowired arguments in lifecycle and test
methods. Specifically, if a developer sets the ExtensionContextScope to
TEST_METHOD — for example, by configuring the following configuration
parameter as a JVM system property or in a `junit-platform.properties`
file — the SpringExtension already supports dependency injection from
the current, @⁠Nested ApplicationContext in @⁠Autowired fields in an
enclosing class of the @⁠Nested test class.

junit.jupiter.extensions.testinstantiation.extensioncontextscope.default=test_method

However, there are two scenarios that fail as of Spring Framework
6.2.12.

1. @⁠TestConstructor configuration in @⁠Nested class hierarchies.
2. Field injection for bean overrides (such as @⁠MockitoBean) in
   @⁠Nested class hierarchies.

Commit 82c34f7 fixed the SpringExtension to support scenario #2
above.

To fix scenario #1, this commit revises
BeanOverrideTestExecutionListener's injectField() implementation to
look up the fields to inject for the "current test instance" instead of
for the "current test class".

This commit also introduces tests for both scenarios.

See spring-projectsgh-34576
See spring-projectsgh-35676
Closes spring-projectsgh-35680
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Improve BeanFactory/ObjectProvider to select the only one default candidate among non-default candidates

2 participants

@Pankraz76 @quaff