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
Spring-specific index file for component candidate classes [SPR-11890] #16509
Comments
cemo koc commented Is this approach decreasing startup times dramatically, isn't it? :) This approach can be supported by some build plugins and a very fast startup time can be achieved. |
Stéphane Nicoll commented I have a first prototype that generates a Loading the index is quite cheap but I'd like to investigate an option where it's loaded only once (and on-demand). There some hacking in this branch |
Stéphane Nicoll commented Commit dc160f6 contains a first attempt at producing and using the index within the framework code base. Two areas are covered for the moment:
The implementation is completely transparent: you use Performance wise, it's not super impressive:
That's the mean of 3 separate executions of a full (Spring Boot) application bootstrap (i.e. including the hibernate bootstrap). The advantage of the index is that the time required to scan candidates is basically constant regardless of the size of the project. One thing that the implementation doesn't support is the use of custom include filters: the index only knows about a limited set of candidates so as soon as a custom include is set, we have to ressort to classpath scanning. In the app that was tested, several traditional classpath scanning were operated even though the index is available:
The first two are looking in Spring Data's own package space so it's not that bad since the size of the package is constrained. Still, Spring Data may generate some meta-data file they could lookup rather than scanning the classpath for components. For the latter, |
Stéphane Nicoll commented After yet another review with Juergen Hoeller I've improved the current proposal. A new The next step is to change
It was also identified that it would be nice if the ASM |
Stéphane Nicoll commented This feature has now been merged to master. There are still work to do in other projects, typically by adding the Juergen Hoeller could you please review and backport Starting a Spring Boot application with all kinds of use cases now transparently uses only the index, except when There is another occurrence of |
Oliver Drotbohm commented The reason for our own scanning is that we need to find out whether we have to wire a custom repository implementation to the proxy or not. If we relied on the users declaring the implementation class as Spring bean, we can't be sure that bean definition is already available in the registry and thus we can't reliably decide whether to configure a runtime bean reference or not. If the container provided means to create an optional bean reference by name, we could we could drop our own scanning. |
Stéphane Nicoll commented A first cut is available on master, see links for further tuning of this feature in future 5.0 milestones. |
Petar Tahchiev commented Hey guys, is there any API to interact with the generated index? I want to select all the classes that have the |
Juergen Hoeller opened SPR-11890 and commented
Instead of or in addition to externally provided index arrangements (such as on JBoss), Spring could define its own index file: e.g. a "META-INF/spring.components" file listing pre-generated component candidate names (one per line) in order to shortcut the candidate component identification step in the classpath scanner. That file could get generated by a platform-specific deployer or simply by an application build task.
Such a list in an index file wouldn't have to be definitive: Spring would still evaluate each and every one of those classes individually via ASM but wouldn't bother with evaluating any other classes in such a jar file. We could also consider using such a file for Spring-driven JPA entity scanning.
Issue Links:
@Indexed
to the 4.3.x line2 votes, 11 watchers
The text was updated successfully, but these errors were encountered: