AbstractContainer.callInitializingBeans instantiates beans regardless of their spring scope to check instanceof InitializingBean


AbstractContainer.callInitializingBeans attempts to create instances of all known bean names, regardless of their spring scope.

This can cause session scoped beans to get the initialized before their dependencies can be resolved and their requirements such as the user being authenticated are met.

The stack is as follows during the very first access to the webapp:

MyUserSessionScopedBean.initialize() line: 94
LifeCyclePostBeanPostProcessor.postProcessAfterInitialization(Object, String) line: 30
DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).applyBeanPostProcessorsAfterInitialization(Object, String) line: 361
DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).initializeBean(String, Object, RootBeanDefinition) line: 1344
DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).doCreateBean(String, RootBeanDefinition, Object[]) line: 473
AbstractAutowireCapableBeanFactory$1.run() line: 409
AccessController.doPrivileged(PrivilegedAction<T>, AccessControlContext) line: not available [native method]
DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).createBean(String, RootBeanDefinition, Object[]) line: 380
AbstractBeanFactory$2.getObject() line: 302
UserSessionScope.get(String, ObjectFactory) line: 51
DefaultListableBeanFactory(AbstractBeanFactory).doGetBean(String, Class, Object[], boolean) line: 298
DefaultListableBeanFactory(AbstractBeanFactory).getBean(String, Class, Object[]) line: 185
DefaultListableBeanFactory(AbstractBeanFactory).getBean(String) line: 164
SpringContainer.getBean(String) line: 85
SpringContainer(AbstractContainer).callInitializingBeans() line: 40
SpringContainer(DefaultContainer).setupFinished() line: 181
DwrSpringServlet.init(ServletConfig) line: 95

I've verified that this problem exists for both the 2.0.X and 3.0.X code trees. It either causes session scoped beans to throw exceptions due to being instantiated too early, or will leave them in an invalid state. Bottom line is that DWR shouldn't attempt to instantiate them, and that this bug can prevent the spring context beans from being properly set up.

A possible solution is to use ListableBeanFactory.getBeansOfType(InitializingBean.class) instead of the current callInitializingBeans implementation which uses instanceof InitializingBean.


Jim Meyer
February 3, 2012, 1:05 AM

Hi David.

Added the jar at http://ci.directwebremoting.org/bamboo/browse/DWR20-ALL-82/artifact/JOB1/dwr.jar/dwr.jar to local rep and ran the test case (which doesn't fail with 3.0-RC2) but it still fails.

I see that there's changes in AbstractContainer but they don't seem to have done the trick.

David Marginian
February 3, 2012, 4:43 AM

Sorry Jim. Try again - http://ci.directwebremoting.org/bamboo/browse/DWR20-ALL-84/artifact. This one should do the trick (had time to test it).

Jim Meyer
February 3, 2012, 5:21 AM

Build 84 did the trick. ScopedBean is no longer one of the bean names in AbstractContainer.callInitializingBeans.

David Marginian
February 3, 2012, 5:26 AM

Thanks Jim. I will try to release 2.0.10 in the next week or so.

David Marginian
February 7, 2012, 6:31 PM

I just pushed out 2.0.10 with this fix. It will be in Maven central in a few hours. I will update the site in the coming days.


David Marginian


Jim Meyer



Documentation Required



Fix versions