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

[spring-projects-issues]

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:

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

1 votes, 2 watchers

[spring-projects-issues]

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-projects-issues]

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-projects-issues]

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]

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.