Easiest way to get HibernateInterceptor to be called

[andrew_null]

Hello everyone,

I'm using Spring's HibernateInterceptor for my DAOs, in order to get sessions attached to them. Here's an example of my TargetProxy:

<bean id="MemberDAOTarget" class="org.phatcast.db.dao.MemberDAOImpl"  factory-method="getInstance">
        <property name="sessionFactory">
            <ref bean="mySessionFactory"/>
        </property>
    </bean>
	<bean id="MemberDAO" class="org.springframework.aop.framework.ProxyFactoryBean">
	  <property name="proxyInterfaces">
	    <value>org.phatcast.db.dao.MemberDAO</value>
	  </property>
	  <property name="interceptorNames">
	    <list>
	      <value>myHibernateInterceptor</value>
	      <value>MemberDAOTarget</value>
	    </list>
	  </property>
	</bean>

The problem I have is, when I have controllers that need access to the DAOs, it's awkward to inject the DAOs through every time. I was mistakenly using MemberDAO.getInstance() in the code, until I realized the getInstance() call bypasses the HibernateInterceptor.

Is there an easy way to get access to these DAOs without constantly creating setDao() methods in every controller, and changing the XML around? Is anyone is directly looking up the beans in the ApplicationContext? Or any other thoughts?

I would very much appreciate it if anyone had advice as to the best way to use HibernateInterceptor.

Andrew
Seattle, WA

[Colin Yates]

I don't think there is because the main philosophy (how to spell?) is about dependency injection.

BeanA should never construct BeanB. BeanA should be provided with an instance of BeanB. If BeanA calls Singleton.getInstance() how will you provide a mock object for testing of BeanA?

If it really is a problem (which I don't think it is) then create a base class with setDAO(final DAO dao) and extend that. I can't believe I just recommended that! Urgh!

Anyways, the benefits of keeping construction code out of your classes and just injecting collaborators *far* outweigh the inconvenience.

BTW; have you looked at autowiring in spring context to avoid having to explitly define setter injection?

[andrew_null]

Yeah, that works for me. And we're going to switch to autowiring Thanks.

Andrew

[Colin Yates]

Be *very* careful with autowiring by type, use autowire by name instead.