Delay discovery / load where possible #416

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

Comments

Projects
None yet
1 participant
@seancorfield
Member

seancorfield commented Jan 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@seancorfield

seancorfield Jan 4, 2016

Member

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.

Member

seancorfield commented Jan 4, 2016

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