How Common to Spring Manage Beans Created By Hibernate?

I just performed some basic tests to see if there is a speed difference between autowiring and the prototype. For my tests, it was 10.6% faster to use the prototype map than to use autowiring.

Just a note.

I am new to Spring, could some one please post the xml config settings for getting the SpringInterceptor up and running?

thanks in advance.

Quote:

---

Originally Posted by sfwalter

I am new to Spring, could some one please post the xml config settings for getting the SpringInterceptor up and running?

thanks in advance.

---

Something like the following is what I had, though your needs might be different (might not want lazy-init set to true, might not use JTA, etc):

Code:

---

<bean id="dependencyInjectionInterceptor" class="org.springframework.orm.hibernate.support.DependencyInjectionInterceptorFactoryBean">
    <property name="sessionFactoryName">
        <value>sessionFactory</value>
    </property>
    <property name="defaultAutowireMode">
        <value>0</value>
    </property>
    <property name="managedClassNamesToPrototypeNames">
        <props>
            <prop key="com.thatone.archie.engine.task.MoveTask">moveTask</prop>
            <prop key="com.thatone.archie.engine.task.DeleteTask">deleteTask</prop>
            <prop key="com.thatone.archie.engine.task.CopyTask">copyTask</prop>
            <prop key="com.thatone.archie.persistence.ArchieDataSourceImpl">archieDataSource</prop>
            <prop key="com.thatone.archie.engine.job.QuartzJobImpl">archieJob</prop>
        </props>
    </property>
</bean>
<bean id="sessionFactory"
    class="org.springframework.orm.hibernate.LocalSessionFactoryBean" lazy-init="true">
    <property name="dataSource">
        <ref local="wrappedAppDataSource"/>
    </property>
    <property name="mappingResources">
        <list>
            <value>hbm/ApplicationModel.hbm.xml</value>
            <value>hbm/ArchieWorkflow.hbm.xml</value>
            <value>hbm/Datasource.hbm.xml</value>
            <value>hbm/Job.hbm.xml</value>
            <value>hbm/Signature.hbm.xml</value>
            <value>hbm/Task.hbm.xml</value>
            <value>hbm/Context.hbm.xml</value>
            <value>hbm/workflow/HibernateCurrentStep.hbm.xml</value>
            <value>hbm/workflow/HibernateHistoryStep.hbm.xml</value>
            <value>hbm/workflow/HibernateWorkflowEntry.hbm.xml</value>
            <value>hbm/workflow/PropertySetItemImpl.hbm.xml</value>
        </list>
    </property>
    <property name="hibernateProperties">
        <ref local="hibernateProperties"/>
    </property>
    <property name="entityInterceptor">
        <ref local="dependencyInjectionInterceptor"/>
    </property>
    <property name="jtaTransactionManager">
        <ref local="jotm"/>
    </property>
</bean>

---

I've omitted non-essential bean definitions, but those are the crucial ones.

hth,

calvin

Quote:

---

Originally Posted by sethladd

Hello,

We've heard time and time again to "put business logic inside your business objects". Most of the time, full business logic requires dependencies to be injected in my business object. The business objects themselves (Business, Account, etc) are managed by Hibernate. Their dependencies are/should be managed by Spring.

How common is this? If my business object is something that comes from the database, but requires external dependencies, then Spring must create and wire up my object.

This seems fair and good, but I haven't seen many examples of this usage. It makes me wonder if my business domain objects (those that come from the database) should ever rely on external dependencies.

My gut says yes: keep business logic in business object. Note: this does not mean DAO type actions.

Of course, I could keep the business objects free from external dependencies, but then their ability to do work is greatly lessened.

Thoughts? Comments? War stories?

Thanks very much!
Seth

---

If you use dependency injection (Spring beans) how would you like to solve the issue that a persistent object lives only as long as the transaction lives?
If you create a Spring bean and it references a persistent object you'll get an exception if the next transaction tries to access the referenced object. This is because the object is only valid for the transaction it was loaded. After commit/rollback the association with the DB is lost.

I think you are talking about how once you close the session, you aren't able to traverse lazy loaded relationships. That is true. It's a good practice to load up all relationships needed for the use case before the session is closed. Then, when that object "goes out into the wild", you have loaded everything.

We've been DI'ing our Hibernate objects for some time with great success. I think it was a key missing ingredient for a true OO system.

Did I misinterpret the meaning of your post?

I see that the lates code in the sandbox (at least that I could find) related to this has not been updated in over a year and never made it into the actual framework. Currently, using Hibernate 3 without Hibernate 2 in the classpath breaks the sandbox code, as it relies on Hibernate 2 Interceptor (net.sf) syntax. Not intending to re-open old wounds, but what's the current thinking on how
best to address this type of functionality?

thanks,
Zach

My understanding is, @Configure+AspectJ is the preferred way to achieve this in Spring 2.0.

Thanks for the follow-up. Since my post, I noticed that approach referenced here:

http://www.springframework.org/docs/reference/aop.html
in section 6.8.1

As well as some approaches here:
http://debasishg.blogspot.com/2006/0...ur-domain.html

While I like aspectj, on large development teams it isn't always possible to force aspectj weaving on everyone. In addition, the documentation in 6.8.1 does reference DependencyInjectionInterceptorFactoryBean, but when I look at both the svn and cvs repository here, I don't see the bean.

I'm going to investigate further the blog post referenced above to see if I can figure out a decent, non-aspectj solution to this problem, outside of apparently DependencyInjectionInterceptorFactoryBean, unless I can find (or am told about) an up to date version somewhere.

thanks,
Zach