You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
Currently
addBean()
(and similar methods) cause bean discovery which causes loading, which means that FW/1'saddBean()
call -- to add itself -- happens after the load listener runs, which will be problematic if the load listener tries toload()
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 callgetBean("fw")
to dump configuration information.The text was updated successfully, but these errors were encountered: