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

Add bean definition attribute for ConfigurationClassPostProcessor to skip "lite" bean detection [SPR-17412] #21945

Closed
spring-issuemaster opened this issue Oct 19, 2018 · 4 comments
Assignees

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Oct 19, 2018

Dave Syer opened SPR-17412 and commented

ConfigurationClassPostProcessor does a lot of wheel spinning, even in an app with zero @Configuration classes. If there was a bean definition attribute that told it "don't analyze this class" we could short circuit a lot of that processing in a higher level tool (e.g. in Spring Boot).


Affects: 5.1.1

Issue Links:

  • #21379 A lite configuration class's member classes are processed when it's imported but not when it's registered directly
  • #21739 Revisit @Bean introspection between @Configuration classes and 'lite' beans

1 votes, 2 watchers

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Oct 19, 2018

Dave Syer commented

It's a little bit more complicated than just adding a bean definition attribute because ConfigurationClassParser also looks at all nested member classes of @Configuration classes, which are inspected directly through their class metadata, not through a bean definition. So to prevent that busy work we need a way to block the "lite" check in member classes too - something like a rule that no "lite" class is itself a member class of a @Configuration.

UPDATE: that check is already in place up to a point (it only processes member classes inside @Component):

if (configClass.getMetadata().isAnnotated(Component.class.getName())) {
     // Recursively process any member (nested) classes first
     processMemberClasses(configClass, sourceClass);
}

That doesn't prevent the "lite" check being applied to member classes of @Components, but probably that would be a good goal.

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Oct 19, 2018

Dave Syer commented

A further complication is that ConfigurationClassPostProcessor adds bean definitions and then processes them looking for more @Configuration classes. Those bean definitions don't go through any post processors until after the ConfigurationClassPostProcessor has finished working (so incidentally a BeanDefinitionRegistryPostProcessor never sees them), which means anyone seeking to add the eponymous attribute from this issue will struggle to find a place to insert a callback. Unless we can impose further restrictions on "lite" configurations I don't see an easy way round that with the current lifecycle. Still thinking...

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Oct 19, 2018

Dave Syer commented

Here's what such a change could look like: dsyer@c16a298. It works for me, in the sense that it cuts out 99% of @Bean scanning in a vanilla Spring Boot application. To deal with the last comment I found it useful to add the attribute actually within ConfigurationClassBeanDefinitionReader to beans that were assumably not "lite" config (ones that have @Configuration or were created from a @Bean method).

I can make that into a pull request if you want. I expect you have other better ideas though.

@jhoeller
Copy link
Contributor

@jhoeller jhoeller commented Mar 13, 2019

It looks like this will be covered by our programmatic annotation exclusion facilities where certain bean classes can be registered as non-annotated, or only annotated with specific annotations. All of our common annotation introspection algorithms use a central AnnotationUtils.isCandidateClass hook for those purposes already, including ConfigurationClassPostProcessor. We just need to define a proper programmatic API for registering such exclusions that can be picked up by the isCandidateClass check still, along with our revised spring-context-indexer which will populate the same annotation exclusion API.

@jhoeller jhoeller closed this Mar 13, 2019
@jhoeller jhoeller removed this from the 5.2 M1 milestone Apr 10, 2019
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
You can’t perform that action at this time.