Announcement Announcement Module
No announcement yet.
How Common to Spring Manage Beans Created By Hibernate? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    I've updated the Javadoc. Thanks for bringing this to my attention.


    • #47
      There is a slight inconsistency with how Hibernate might wire a bean's ID and how this new interceptor is doing it.

      The interceptor will use BeanWrapper.setPropertyValue to set the ID. This will not work if the bean has only a getter for the ID (and only field access for the ID). If no setter exists, then a NotWritablePropertyException is thrown.

      Hibernate, on the other hand, is able to use field access to set properties of a bean.

      I wonder if the interceptor should first try setPropertyValue, and if it fails, to try setting the field directly? We removed our setId() method to make it more clear users aren't able to set this. We'll set it to private for now, but if we're able to set the ID via its field, that would be even better.

      Any reason not to?


      • #48
        Actually, turns out I have to create a public setId() to get it to work with setPropertyValue.

        I'd like to be able to work with private setters, or even better yet, just accessing the field. If this is a good idea, I'll post the patch.


        • #49
          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.


          • #50
            ApplicationContext Config

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

            thanks in advance.


            • #51
              Re: ApplicationContext Config

              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):

              <bean id="dependencyInjectionInterceptor" class="">
                  <property name="sessionFactoryName">
                  <property name="defaultAutowireMode">
                  <property name="managedClassNamesToPrototypeNames">
                          <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>
              <bean id="sessionFactory"
                  class="org.springframework.orm.hibernate.LocalSessionFactoryBean" lazy-init="true">
                  <property name="dataSource">
                      <ref local="wrappedAppDataSource"/>
                  <property name="mappingResources">
                  <property name="hibernateProperties">
                      <ref local="hibernateProperties"/>
                  <property name="entityInterceptor">
                      <ref local="dependencyInjectionInterceptor"/>
                  <property name="jtaTransactionManager">
                      <ref local="jotm"/>
              I've omitted non-essential bean definitions, but those are the crucial ones.




              • #52
                Re: How Common to Spring Manage Beans Created By Hibernate?

                Originally posted by sethladd

                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!
                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.


                • #53
                  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?


                  • #54
                    Current approach

                    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?



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


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

                        in section 6.8.1

                        As well as some approaches here:

                        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.