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

Avoid creation of lazy candidates when the primary bean is injected [SPR-14611] #19178

Closed
spring-projects-issues opened this issue Aug 21, 2016 · 1 comment
Assignees
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Aug 21, 2016

Asaf Romano opened SPR-14611 and commented

Consider the following code in a Config class:

    @Bean(name = "sharedExecutorService")
    @Primary
    @Lazy
    public ExecutorService sharedExecutorService()
    {
        System.out.println("In sharedExecutorService");
        ExecutorService executorService = Executors.newFixedThreadPool(5);
        System.out.println(String.format("Created: %s", executorService));
        return executorService;
    }

    @Bean(name = "localExecutorService1")
    @Lazy
    public ExecutorService localExecutorService1()
    {
        System.out.println("In localExecutorService1");
        ExecutorService executorService = sharedExecutorService();
        System.out.println(String.format("Created: %s", executorService));
        return executorService;
    }

    @Bean(name = "localExecutorService2")
    @Lazy
    public ExecutorService localExecutorService2()
    {
        System.out.println("In localExecutorService2");
        ExecutorService executorService = sharedExecutorService();
        System.out.println(String.format("Created: %s", executorService));
        return executorService;
    }

Later on, someone injects the primary bean as follows:

@Inject
private ExecutorService executorService;

The expectation is for the primary bean to be constructed and injected at this point, but for the other two beans not to be constructed yet (as they are lazy). What seems to happen, however, is that all three beans are constructed at this point (albeit the primary bean is successfully injected).

Please note that this issue seems to be quite similar to #18314


Affects: 4.3.2

Issue Links:

  • #12206 findDefaultEntityManagerFactory should consider EMF bean's primary flag
  • #18314 BeanFactoryAnnotationUtils.qualifiedBeanOfType should not instantiate all beans of given type before checking qualifier

Referenced from: commits c4fcdb6, a7849b2

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 24, 2016

Juergen Hoeller commented

I've addressed this through a revision of DefaultListableBeanFactory's resolution algorithms, only resolving bean instances when already available and otherwise operating against the bean type until an instance has actually been selected for exposure. This still allows for proper introspection of primary candidates and priority values but does not trigger unnecessary bean creation.

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

Successfully merging a pull request may close this issue.

None yet
2 participants