Announcement Announcement Module
Collapse
No announcement yet.
How to config autowiring objects under a particular package? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to config autowiring objects under a particular package?

    Hi,

    I would like to know if there is a way to simplify object injection, especially when a same object is being injected to many other objects e.g. a Hibernate session factory object is required to all DAO objects. Shown below is my spring config:

    <beans>

    <bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSes sionFactoryBean">
    ...
    </bean>

    <bean id="accountDAO" class="com.xyz.dao.impl.AccountDAOImpl">
    <property name="sessionFactory">
    <ref bean="sessionFactory" />
    </property>
    </bean>

    <bean id="customerDAO" class="com.xyz.dao.impl.CustomerDAOImpl">
    <property name="sessionFactory">
    <ref bean="sessionFactory" />
    </property>
    </bean>

    ...

    </beans>

    Thanks.

    Regards,
    Koala Lam

  • #2
    One of the way may be using a parent bean, something like
    Code:
    <bean id="abstractDao" abstract="true">
        <property name="sessionFactory">
              <ref bean="sessionFactory" />
        </property>
    </bean>
    
    <bean id="accountDAO" class="com.xyz.dao.impl.AccountDAOImpl" 
        parent="abstractDao" />
    
    <bean id="customerDAO" class="com.xyz.dao.impl.CustomerDAOImpl"
        parent="abstractDao" />
    </bean>

    Comment


    • #3
      Originally posted by al0 View Post
      One of the way may be using a parent bean
      +1 from me.

      Autowiring (of any kind) is a really bad idea. It has many restrictions but the biggest problem is that of readability.

      The Spring XML files are in essence your application blueprint. It explains how the application is wired together (which beans go where) and where your boundaries are (i.e. transactional, security, remoting).

      It isn't just config, it is really crucial

      Comment


      • #4
        And if you don't believe me, the very next post I am going to look at should convince you

        http://forum.springframework.org/sho...791#post135791

        Comment


        • #5
          And there is one more reason against it - it makes configuration more fragile.

          When you maintain your application during its lifecycle (likely many monats or even years after deploying) it becomes not so easily to predict effect of configuration changes when autowiring is in effect. So it can save you some work right now, but most likely you will dearly pay for it in the future.

          Regards,
          Oleksandr

          Comment


          • #6
            Originally posted by al0 View Post
            And there is one more reason against it - it makes configuration more fragile.
            It's also one of the most common problems people have with the Spring test classes, they don't read the docs and don't realise autowiring is going on!

            Comment

            Working...
            X