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

DI/1: extension point for handling missing bean #390

Closed
seancorfield opened this Issue Oct 23, 2015 · 2 comments

Comments

Projects
None yet
1 participant
@seancorfield
Member

seancorfield commented Oct 23, 2015

If you call getBean(beanName) and it doesn't exist, it would be nice to be able to easily override that behavior so that you could, for example, delegate to a factory bean that uses a convention to create beans (such as we do at World Singles -- and which came up in discussion with @jtreher on the CFML Slack today).

@seancorfield seancorfield added this to the 3.6 milestone Oct 23, 2015

@seancorfield seancorfield self-assigned this Oct 23, 2015

@seancorfield

This comment has been minimized.

Show comment
Hide comment
@seancorfield

seancorfield Oct 31, 2015

Member

We already have missingBean() but it only throws an exception if strict is enabled in the configuration since it allows missing dependencies to be ignored (just logging them to the console).

I think at this point I'd be inclined to still call it but add a third, optional, argument dependency which defaults to true (and pass false from getBean()). This may break user code that overrides missingBean() -- since it will not expect to be called if getBean() fails -- but I think that's an extreme edge case (since such code must be expecting getBean() to throw an exception and their overridden missingBean() function must do something other than throw an exception).

Note that missingBean() currently returns void which will also have to change. Then I'll have to consider whether calling missingBean() for dependencies should be allowed to automatically return a new bean, as if by convention / factory bean.

Member

seancorfield commented Oct 31, 2015

We already have missingBean() but it only throws an exception if strict is enabled in the configuration since it allows missing dependencies to be ignored (just logging them to the console).

I think at this point I'd be inclined to still call it but add a third, optional, argument dependency which defaults to true (and pass false from getBean()). This may break user code that overrides missingBean() -- since it will not expect to be called if getBean() fails -- but I think that's an extreme edge case (since such code must be expecting getBean() to throw an exception and their overridden missingBean() function must do something other than throw an exception).

Note that missingBean() currently returns void which will also have to change. Then I'll have to consider whether calling missingBean() for dependencies should be allowed to automatically return a new bean, as if by convention / factory bean.

@seancorfield

This comment has been minimized.

Show comment
Hide comment
@seancorfield

seancorfield Oct 31, 2015

Member

Need to document the extension point.

Member

seancorfield commented Oct 31, 2015

Need to document the extension point.

seancorfield added a commit that referenced this issue Nov 1, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment