-
Notifications
You must be signed in to change notification settings - Fork 38.5k
Deprecate SpringFactoriesLoader#loadFactoryNames #27954
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
Comments
Update `SpringFactoriesLoader` so that factory implementation classes can have a constructor with arguments that are resolved dynamically. Arguments are resolved using a `ArgumentResolver` interface that is passed to the `loadFactories` method. This strategy interface is intentionally simple and only allows resolution based on the argument type. A number of convenience methods are provided to allow resolvers to be built. For example: ArgumentResolver.of(String.class, "tests") .and(Integer.class, 123); Factory implementation classes must have a non-ambiguous constructor in order to be instantiated. The `SpringFactoriesLoader` uses the same algorithm as `BeanUtils.getResolvableConstructor`. See spring-projectsgh-27954 Co-authored-by: Madhura Bhave <[email protected]> Co-authored-by: Andy Wilkinson <[email protected]>
Add an additional `FactoryInstantiationFailureHandler` strategy interface to `SpringFactoriesLoader` to allows instantiation failures to be handled on a per-factory bases. For example, to log trace messages for only factories that can't be created the following can be used: FactoryInstantiationFailureHandler.logging(logger); If no `FactoryInstantiationFailureHandler` instance is supplied then `FactoryInstantiationFailureHandler.throwing()` is used which provides back-compatible behavior by throwing an `IllegalArgumentException`. See spring-projectsgh-27954 Co-authored-by: Madhura Bhave <[email protected]> Co-authored-by: Andy Wilkinson <[email protected]>
Actually the related issue doesn't deprecate the method so let's reopen this one. |
Moving to the next milestone since we just introduce the infrastructure and we'd need to give some time for team to use it before deprecating |
"Blocked" by spring-projects/spring-boot#29699 |
If we deprecate
Unfortunately, both of these methods are |
Can you please create an issue to get rid of its use? 6.0 is the right time to break this contract if we have to. |
See: |
Since SpringFactoriesLoader.loadFactoryNames() will be deprecated in gh-27954, this commit removes the use of it in the spring-test module. Specifically, this commit removes the protected getDefaultTestExecutionListenerClasses() and getDefaultTestExecutionListenerClassNames() methods from AbstractTestContextBootstrapper and replaces them with a new protected getDefaultTestExecutionListeners() method that makes use of new APIs introduced in SpringFactoriesLoader for 6.0. Third-party subclasses of AbstractTestContextBootstrapper that have overridden or used getDefaultTestExecutionListenerClasses() or getDefaultTestExecutionListenerClassNames() will therefore need to migrate to getDefaultTestExecutionListeners() in Spring Framework 6.0. Closes gh-28666
This issue is no longer blocked by #28666. Though I suppose it's still blocked by spring-projects/spring-boot#29699. |
Uh oh!
There was an error while loading. Please reload this page.
As seen in #27753, the
SpringFactoriesLoader#loadFactoryNames
(introduced in #15158 ) has been very useful over the years but is too permissive for our AOT and native work. Some existing use cases can use reflection in a way that's not predictable for AOT processors.Here are three example use cases in Spring Boot:
ConfigDataLoader
class names and are calling non-default constructors using a set of dependencies maintained locallyInstead of Strings, the replacement should return a different type that allows for the actual type inspection and a Supplier to get an actual instance. Maybe something similar to
ServiceLoader.Provider
. This proposal will probably not solve the two use cases mentioned above, so we'll need to find proper replacements in Spring Boot or provide new features in Spring Framework to support them.The text was updated successfully, but these errors were encountered: