Skip to content
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

Delay discovery / load where possible #416

Closed
seancorfield opened this issue Jan 4, 2016 · 1 comment
Closed

Delay discovery / load where possible #416

seancorfield opened this issue Jan 4, 2016 · 1 comment
Assignees
Milestone

Comments

@seancorfield
Copy link
Member

Currently addBean() (and similar methods) cause bean discovery which causes loading, which means that FW/1's addBean() call -- to add itself -- happens after the load listener runs, which will be problematic if the load listener tries to load() singletons and a user is letting DI/1 manage their controllers.

It also means that fw is not available as a bean inside the load listener (which is not a big deal unless you're trying to manipulate controllers -- or FW/1 itself -- inside your load listener, which is probably not good practice), which has the side effect of making it harder to debug problems with initialization, since you can't call getBean("fw") to dump configuration information.

@seancorfield seancorfield self-assigned this Jan 4, 2016
@seancorfield seancorfield added this to the 4.0 milestone Jan 4, 2016
@seancorfield
Copy link
Member Author

Given that order of initialization is not actually documented and that recommended practice is to only call these methods in a load listener, no changes to the documentation need to be made.

This makes the fw edge case work and delays discovery / load to first use as was intended.

Only addAlias() forces discovery / loading now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant