Announcement Announcement Module
No announcement yet.
autowire and autowire-candidate not working... Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • autowire and autowire-candidate not working...

    I run my application in two different contexts...

    In Websphere using the websphere transaction manager, and locally - hibernate transaction manager.

    When running locally the instantiation of the org.springframework.transaction.jta.WebSphereTrans actionManagerFactoryBean class fails (not in websphere and websphere stuff not on the classpath).

    That is fine, I specify that singleton bean to by lazy-init=true.


    Now I want to use autowire="byType" on another bean. This causes that websphere transacation factory bean to be instantiated! I get that, it needs to know what type it is for the autowire.

    However, when I specify the autowire-candidate="false" for the transaction factory bean it does not make any difference. It still tries (and fails) to instantiate it?

    What's going on? Is this expected behaviour? Is this a bug?

  • #2
    Is it possible to see the applicationContext.xml that is causing this problem? Make it easier to see what you're describing.


    • #3
      In Websphere using the websphere transaction manager, and locally - hibernate transaction manager.

      When running locally the instantiation of the org.springframework.transaction.jta.WebSphereTrans actionManagerFactoryBean class fails (not in websphere and websphere stuff not on the classpath).
      You state that locally you use the HibernateTransactionManager and in websphere the WebSphereJTransactionmanager. Why do you even have that one around in your local configuration?
      Isn't it possible to create 2 configuration files, one containing the local configuration the other the one for websphere. Depending on the environment (or build) you can decide which one to use.


      • #4
        The following file exhibits the behaviour...

        The file is a simplified version of the environment as the reality has 7 spring config files. If I execute the application with the following file specified in the beanRefFactory.xml, loaded by a SingletonBeanFactoryLocator then it tries to create the websphere tran manager - which fails.

        However, if I turn _off_ the autowire on the business.employeebenefits bean then it works fine.

        btw, using spring 2.0.2
        <?xml version="1.0" encoding="UTF-8"?>
        <beans xmlns="" xmlns:xsi=""
          default-autowire="no" default-lazy-init="false" default-dependency-check="none">
          <bean id="business.employeebenefits" class="" autowire="byType"
            <property name="messageSource">
              <ref bean="messageSource" />
            <property name="dataIntegrityValidator">
              <ref bean="validator.dataintegrity" />
            <property name="genericDao">
              <ref bean="dao.generic" />
          <!-- The Message Source bean -->
          <bean id="messageSource" class="">
            <property name="basenames">
          <bean id="validator.dataintegrity" class="">
            <property name="personDao">
              <ref bean="dao.person" />
            <property name="userDao">
              <ref bean="dao.user" />
            <property name="financialDao">
              <ref bean="" />
            <bean id="containerTranMngr" class="org.springframework.transaction.jta.JtaTransactionManager" lazy-init="true" autowire-candidate="false">
            <property name="userTransactionName">
            <null />
            <property name="transactionManager" ref="websphere.transaction.manager" />
            <bean id="websphere.transaction.manager"
            class="org.springframework.transaction.jta.WebSphereTransactionManagerFactoryBean" lazy-init="true" autowire-candidate="false"/>
          <bean id="dao.person" class="">
            <property name="sessionFactory">
              <ref bean="hibernate.sessionfactory" />
          <!-- **********************  CONFIGURE SESSION FACTORY - START ********************* -->
          <bean id="hibernate.sessionfactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean"
            <property name="dataSource" ref="jdbcDS" />
            <property name="schemaUpdate" value="false" />
            <property name="hibernateProperties">
                <prop key="hibernate.dialect">org.hibernate.dialect.DIALECT</prop>
                <prop key="hibernate.show_sql">false</prop>
                <prop key="hibernate.default_schema">SCHEMA</prop>
                <prop key="hibernate.format_sql">true</prop>
            <property name="mappingLocations">
          <bean id="jdbcDS" class="org.springframework.jdbc.datasource.DriverManagerDataSource" lazy-init="true">
            <property name="driverClassName">
            <property name="url">
            <property name="username">
            <property name="password">


        • #5
          I can use different files for the different environments, but that means more complexity. I have to have a different build then. If I can avoid that approach then I will. The more consistency there is, the better.


          • #6
            I think the question is what is better. Hacking and patching away on the configuration or create 2 files containing the specified configuration for the different environments. Assuming you are doing that it also means that you have your local configuration some where on the server? I think it would be not so well nice if suddenly the HibernateTransactionManager was the only one there, or it suddenly uses your local datasource instead of the websphere one?

            I think having 2 files is less error prone and clearer then to hack away on the configuration files (imho that is ofcourse ).

            But back on topic.

            I think (Proxy)FactoryBeans are a special case and I'm not sure if it is ignored if you specify the autowire-candidate="false". I will need to have to look at the Spring sources for that.


            • #7
              As far as your two file suggestion, I'd prefer to go with that as well. IMHO also it seems far cleaner, just my 2 cents.


              • #8
                Thanks for the help, the pointer on the behaviour of autowire-candidate on factory beans was key.

                I setup a small test bed to test the behaviour of a factory bean.

                Interesting behaviour...

                The bottom line is that when there is an autowire="byType" in your spring configuration file that will force all the factory beans to be instantiated regardless of their autowire-candidate setting or their lazy-init setting. I suppose when byType is set then the factories are required so they'll be instantiated.

                The autowire attribute on a factory bean does have an influence over whether that object it creates is a candidate for autowiring. However, that does not stop its getObjectType method to be executed.

                So for me to use autowire="byType" I can either create different files for the different environments or I can wrap the WebsphereTransactionManagerFactoryBean and defer its creation to when the getObject is actually called on the factory bean (the default one creates the tm manager in its constructor).

                I agree that in a production release the hibernate tm should be removed, but we are currently in dev.

                What I did not mention is that the ear that is built needs to be able to run in both Jboss and websphere. In Jboss it is using the hibernate tm and websphere uses the websphere one. Doing a whole new build just to change the tm which the ear uses is unacceptable. Currently it only requires a change of a property value and that is what I'd like to retain.