Skip to content

Improve SpringFactories to customize how arguments and instantiation failures are handled #28057

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

Closed
wants to merge 2 commits into from

Conversation

philwebb
Copy link
Member

Two commits that lay the groundwork for deprecating loadFactoryNames.

See #27954

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Feb 16, 2022
@philwebb philwebb force-pushed the gh-27954 branch 3 times, most recently from cafc9cd to f541843 Compare February 16, 2022 22:28
philwebb and others added 2 commits February 16, 2022 15:47
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]>
@jhoeller jhoeller added in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Feb 18, 2022
@jhoeller jhoeller self-assigned this Feb 18, 2022
@jhoeller jhoeller added this to the 6.0.0-M3 milestone Feb 18, 2022
@snicoll
Copy link
Member

snicoll commented Feb 21, 2022

For the record the AOT work in the core container may also use this. In Spring Native, the components that take part of the processing of the ApplicationContext are discovered in spring.factories. It was convenient to provide support for the *Aware interface but if we can replace this by a list of well-defined types, that would be more idiomatic as these components are not beans.

@snicoll snicoll self-assigned this Mar 15, 2022
@snicoll snicoll changed the title SpringFactories ParameterResolver and FactoryInstantiationFailureHandler support Improve SpringFactories to customize how arguments and instantiation failures are handled Mar 15, 2022
snicoll pushed a commit that referenced this pull request Mar 15, 2022
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 gh-28057

Co-authored-by: Madhura Bhave <[email protected]>
Co-authored-by: Andy Wilkinson <[email protected]>
snicoll pushed a commit that referenced this pull request Mar 15, 2022
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 gh-28057

Co-authored-by: Madhura Bhave <[email protected]>
Co-authored-by: Andy Wilkinson <[email protected]>
snicoll added a commit that referenced this pull request Mar 15, 2022
@snicoll snicoll closed this in 03179aa Mar 15, 2022
@snicoll
Copy link
Member

snicoll commented Mar 15, 2022

Thanks a lot for the contribution @philwebb, @wilkinsona, and @mbhave. Apologies for the delay in merging this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants