Announcement Announcement Module
Collapse
No announcement yet.
Accessing spring services from hibernated domain objects Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Accessing spring services from hibernated domain objects

    All,
    Does anyone have recommendations for getting dependency injection of spring services to work for domain objects that are persisted by hibernate?

    I have a case where it makes sense for a domain object to access a service that's managed by spring.

    My software remotely manages PCs with different operating systems. I have low level services that deal with communicating with the PCs, and these services in turn use hibernate as well.

    Let's say I have an interface called Computer, and various implementations - XPComputer, LinuxComputer, etc. which are persisted by hibernate.

    Essentially, I want to be able to write code that looks like this:
    Code:
    computer.reboot();
    and let polymorphism take care of the rest.

    The implementations of the command could look like this:
    Code:
    XPComputer:
    void reboot() {
        xpCommunicationService.reboot(ipAddress);
       //xpCommunicationService is managed by spring
    }
    
    LinuxComputer:
    void reboot() {
        linuxCommunicationService.reboot(ipAddress);
       //linuxCommunicationService is managed by spring
    }
    Any ideas/recommendations about how this could be achieved?

    Thanks in advance!

  • #2
    We believe that the best way to do this is with AspectJ, and will provide an AspectJ aspect to dependency inject objects--whether or not they are created by Spring--in the near future, when those objects are annotated with an @SpringConfigured annotation. This will work with Hibernate, any other data access framework, or indeed any object constructed in the class loader.

    You might also check out DependencyInjectionInterceptorFactoryBean in the Spring sandbox, which doesn't require AspectJ.

    Comment


    • #3
      Originally posted by Rod Johnson
      We believe that the best way to do this is with AspectJ, and will provide an AspectJ aspect to dependency inject objects--whether or not they are created by Spring--in the near future, when those objects are annotated with an @SpringConfigured annotation. This will work with Hibernate, any other data access framework, or indeed any object constructed in the class loader.
      I think this is a very good development. The fact that the most important objects in the system hava a big problem getting dependencies (this is intensified by Spring because you drop most jndi/singleton solutions to get dependencies) is a serious problem.

      Comment


      • #4
        I agree. Adrian and I are very keen to progress this and we've also spoken to Eric Evans (of Domain-Driven Design fame) about it, to get some input from him.

        Comment


        • #5
          Thank you for clarifying that this is a priority!

          Comment


          • #6
            Corby

            I can understand your frustration here. Once Adrian starts with Interface21 next week, lots of cool things should happen soon

            Rgds
            Rod

            Comment


            • #7
              Thanks!

              Thanks for the Tip, Rod - will certainly check out DependencyInjectionInterceptorFactoryBean - and I'm looking forward to @SpringConfigured! That would certainly be a very useful enhancement - I'm sure this isn't the first time this sort of issue has been brought up

              Cheers,
              Vivek

              Comment


              • #8
                Originally posted by Rod Johnson
                I agree. Adrian and I are very keen to progress this and we've also spoken to Eric Evans (of Domain-Driven Design fame) about it, to get some input from him.
                How are you going to deal with the overhead of dependency injection in all domain objects? I can imagine loads of domainobjects are retrieved from the database, so there will be a lot over overhead. And what about other or-mappers? Can they use the same mechanism?

                Comment


                • #9
                  Originally posted by Alarmnummer
                  How are you going to deal with the overhead of dependency injection in all domain objects?
                  Setter injection in Spring involves two operations:

                  1) By inspecting the structure of the class, the Spring configuration files, and the autowiring rules used (AUTOWIRE_BY_NAME, AUTOWIRE_BY_TYPE, etc.), the container decides which beans must be injected using which setter method.

                  2) The actual setters are invoked to inject the dependencies.

                  All of the 'overhead' you describe occurs in Step 1. Step 2 has negligible performance cost. The beauty of the static annotation approach is that Step 1 can be executed exactly once, on container startup, and only Step 2 has to be executed each and every time that a new domain object is instantiated.

                  Probably not a trivial coding exercise, but that's why they pay the big bucks for Adrian. :wink:

                  Comment


                  • #10
                    Indeed, the overhead for this functionality is pretty low. The cost of the reflective invocation to inject dependencies is near zero now and the actual process of intercepting the creation of a new domain object is very quick due to the AspectJ weaving process.

                    A really early version of this code is available in this blog entry. I will most likely commit an updated version to the sandbox next week in readiness for the upcoming 1.3 development phase starting in full force.

                    Rob

                    Comment


                    • #11
                      Originally posted by robh View Post
                      Indeed, the overhead for this functionality is pretty low. The cost of the reflective invocation to inject dependencies is near zero now and the actual process of intercepting the creation of a new domain object is very quick due to the AspectJ weaving process.
                      Apologies for resurrecting a dead thread, but I was wondering if this was still the case now that Spring 2 is in production? I can't find any actual numbers or testimony on this topic.

                      jason

                      Comment


                      • #12
                        Its a fair question to back up the statement with numbers. In the absence of an answer, you could write some simple tests and prove it. Obviously it would be nice to see those results as well .

                        There are some general performance stats here. These are a little old though.
                        http://docs.codehaus.org/display/AW/AOP+Benchmark
                        Last edited by karldmoore; Jan 5th, 2007, 05:23 PM.

                        Comment


                        • #13
                          I saw several complaints about poor performance using load-time weaving when Spring 2 was released. I don't know how much progress has been made in the subsequent point releases.

                          I use compile-time weaving. I don't have the hard numbers in front of me, but it has been nice and speedy for me.

                          Comment


                          • #14
                            I have also been using @Configuable with compile time weaving without any performance complaint. Initially we had some problems with LTW, but since we switched to compile time weaving, things work out like a charm. The only problem, not related to performance though, is that the dependencies do not get re-injected upon deserialization (if u have such a use case). This is an issue recorded in Spring JIRA and for which Ramnivas has also provided a fix. The fix, will however be 100% fullproof when the next release of AspectJ comes up. But with the current patch, things work out pretty well.

                            Cheers.
                            - Debasish

                            Comment

                            Working...
                            X