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
Juergen suggested to call BeanFactory methods on the BeanFactory instance returned from ConfigurableApplicationContext.getBeanFactory instead of calling the BeanFactory methods available on the AbstractApplicationContext instance. Another way to get hold of the "internal" BeanFactory instead of the ApplicationContext facade is to use BeanFactoryAware for injecting the BeanFactory instance and calling methods on that instance.
However I'd like to be able to use BeanFactory methods directly on the ApplicationContext instance instead without any performance overhead (synchronization).
Lari, which ApplicationContext base class are you deriving from in that scenario? We turn assertBeanFactoryActive into a no-op in a few cases... where getBeanFactory() itself provides such a check already. However, that's not the case for GenericApplicationContext and co which always hold a BeanFactory.
AbstractApplicationContext uses AtomicBoolean instead of synchronization for its active/closed flags now. This also removes the unpleasant lock in assertBeanFactoryActive().
Lari Hotari opened SPR-11863 and commented
Profiling Grails 2.4.x applications shows a lot of blocking in org.springframework.context.support.AbstractApplicationContext.assertBeanFactoryActive
There's a discussion about this in SPR-10307 comments.
Juergen suggested to call BeanFactory methods on the BeanFactory instance returned from ConfigurableApplicationContext.getBeanFactory instead of calling the BeanFactory methods available on the AbstractApplicationContext instance. Another way to get hold of the "internal" BeanFactory instead of the ApplicationContext facade is to use BeanFactoryAware for injecting the BeanFactory instance and calling methods on that instance.
However I'd like to be able to use BeanFactory methods directly on the ApplicationContext instance instead without any performance overhead (synchronization).
Affects: 4.0.5
Issue Links:
Referenced from: commits fac2d80
The text was updated successfully, but these errors were encountered: