Use spring.components only for JARs that define an index

[ascheman]

Affects: 5.2.9

I am trying to use spring-context-indexer on my project. It creates a META-INF/spring-components file with a list of my own beans. So far, so good.

However, if I have additional components on my classpath, e.g., keycloak-spring-boot-starter, these provide beans on their own - but they are not instantiated any longer since they are missing from the generated index. I guess the application container should still perform a classpath search even if some beans could be instantiated right from the index.

On behalf of my customer project I have provided a show case of the problem with one of my pet projects:

• Please clone https://github.com/dukecon/dukecon_feedback,

• Switch to branch feature/spring-context-indexer,

• Call ./mvnw clean test and check for the errors.

• The error can also be found in our Gradle Enterprise test reports at https://gradle.dukecon.org/s/kxjpnfo3bglpy/tests/org.dukecon:dukecon-feedback:surefire:test/org.dukecon.feedback.adapters.jpa.FeedbackStoreJPAPostgresTest/testToSave?anchor=e30&focused-exception-line=0-4-2-0-0#1

• Or on our Jenkins server at https://dev.dukecon.org/jenkins/job/dukecon_feedback/job/feature%252Fspring-context-indexer/2/console

Thanks to @mp911de for discussions and for encouraging me to raise this issue.

[snicoll]

@ascheman thanks for the report. This is working as documented as the context indexer is now a global on/off switch for the whole ApplicationContext.

It is a different topic but I'd argue that keycloack-spring-boot-starter should not use classpath scanning at all. A library, in general, shouldn't.

We've tried in the course of the 5.x line to improve the arrangement in such a way that we can associate an index with a jar and be more flexible (i.e. if we need to scan something and it does not have an index file, fallback on regular classpath scanning). Let's reuse this issue to give that another go.

Final note: unless you have hundreds of beans and you're scanning packages with thousands of classes, we don't believe the indexer makes much of a difference so please keep that in mind as well.

[ascheman]

Thanks for your feedback as well, @snicoll. I was aware from my discussions with other Spring developers that an index only might significantly speed up the start of a Boot application if the applications uses large numbers of beans. My customer's application has at least 130 beans on its own plus the beans of used jars.
Nevertheless, the existing of the index file should not stop the application to work at all as soon as there are other beans from non-indexed components (which is quite common in my experience). This would end up in a general do not use this feature since it generates more problems than it solves recommendation in most projects.
I would be happy to test your new tries.

[snicoll]

My customer's application has at least 130 beans on its own plus the beans of used jars.

The beans of "used jars" don't matter here as most libraries don't use classpath scanning.

I was aware from my discussions with other Spring developers that an index only might significantly speed up the start of a Boot application if the applications uses large numbers of beans.

I am not aware of that conversation but it only makes a "significant difference" with a crazy high number of beans (more in the order of thousands and even more classes to scan). Despite what you may hear on the Internet, classpath scanning is actually very fast. The indexer is indeed a niche solution for those very large applications.

[YuankunZhu2012]

Is there any update on this issue? I am trying to find a way to scan the beans in dependent libs by using indexer.

[snicoll]

Thanks for the nudge. This is largely superseded by our AOT effort in Spring Framework 6. As for your wish to scan beans in dependent lib, I can't comment on that but the indexer is not meant to be used by user code.

[snicoll]

I've created #30431 for the follow-up of deprecating the indexer.