Announcement Announcement Module
Collapse
No announcement yet.
Wrong dependency resolving/getting injected uninitialized beans Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Wrong dependency resolving/getting injected uninitialized beans

    Sometimes I have some problems with the order of the initializing of beans which end in strange "null errors" or even NPEs. The reasons seems to be that beans are made available before they are completely initialized. This happened with Spring 1.2.x and now with 2.0 RC 1 as well.

    Example: In a really huge error message I can somewhere read the following

    Code:
    Error creating bean with name 'corbaConnectionFactory': postProcessAfterInitialization method of BeanPostProcessor [org.springframework.context.support.ApplicationContextAwareProcessor@787c16] returned null for bean [null] with name [corbaConnectionFactory]
    
    ...
    
    org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsAfterInitialization(AbstractAutowireCapableBeanFactory.java:288) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.postProcessObjectFromFactoryBean(AbstractAutowireCapableBeanFactory.java:958) at org.springframework.beans.factory.support.AbstractBeanFactory.getObjectFromFactoryBean(AbstractBeanFactory.java:996)
    The setup looks like the following:

    Code:
      <bean id="corbaManagedConnectionFactory" init-method="init"
            class="com.mycompany.resource.corba.jca.spi.CorbaManagedConnectionFactory">
      </bean>
    
      <bean id="corbaConnectionFactory" class="org.springframework.jca.support.LocalConnectionFactoryBean">
        <property name="managedConnectionFactory" ref="corbaManagedConnectionFactory"/>
        <property name="connectionManager" ref="connectionManager"/>
      </bean>
    Debugging the code I found out that no properties had been set on the LocalConnectionFactoryBean and afterPropertiesSet() never had been called. And it's not understandable why.

    (A better error message could maybe provided by checking for null in LocalConnectionFactoryBean.getObject().)

    Another example I have with Jencks being involved. Jencks' GeronimoTransactionManagerFactoryBean is ApplicationContextAware and stores the ApplicationContext in a field in setApplicationContext(..). But it can happen that when getObject() is called, a NPE is thrown due to not yet set ApplicationContext. Again I don't know why. Even stranger: This error depends on the order of the passed config locations when setting of the ApplicationContext.

    (Actually Jencks is involved in example 1 as well. I have 3 context locations, 5 combinations resulting in the NPE, 1 in the "null error" from example 1. My testcase worked with the 1 combination with Spring 1.2.x, but failed for the other combinations with the NPE as well.)

    Any ideas how this can happen?

    Jörg

  • #2
    BTW, specifying depends-on="corbaManagedConnectionFactory,connectionManage r" on the corbaConnectionFactory explicitely makes my TestCase working, which really points to a bug in dependency resolving. Of course I don't want to specify @depends-on explicitely.

    Comment


    • #3
      Once again ...

      Just to getting it bubbled up in the list as these NPEs are really annoying ...

      How can it happen that a dependency is still null that is tried to be injected (failing with NPE at AbstractAutoProxyCreator.postProcessAfterInitializ ation() in line 239 in Spring 2.0 RC2, bean is null, bean.getClass() fails)?

      Jörg

      Comment


      • #4
        circular dependency somewhere?

        BTW: to make a post just to bubble your message up is sort of lame. Other people have real problems too.

        Comment


        • #5
          if it were a circular dependency, the Spring would crash with other error messages.

          Comment


          • #6
            Originally posted by bpolka
            circular dependency somewhere?
            No I don't think so. I mentioned some things that speak against it:

            1. Spring shows different behaviour by just changing the order of the config locations (String[]) passed to ApplicationContext constructor.
            2. It's partly/sometimes fixable by explicitely specifying @depends-on. A circular dependency would not be fixable by this I assume.
            3. Shouldn't Spring detect circular dependencies?

            The actual reason is that afterPropertiesSet() on the org.springframework.jca.support. LocalConnectionFactoryBean does not get called and that's why my ConnectionFactory (retrieved from LocalConnectionFactoryBean.getObject()) is null when it gets injected into other beans. But from what I see and understand this must not happen.

            Jörg

            Comment

            Working...
            X