Accessing spring services from hibernated domain objects

[vivpr]

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:

computer.reboot();

and let polymorphism take care of the rest.

The implementations of the command could look like this:

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!

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

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

[Alarmnummer]

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.

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

[cepage]

Thank you for clarifying that this is a priority!

[Rod Johnson]

Corby

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

Rgds
Rod

[vivpr]

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

[Alarmnummer]

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?

[cepage]

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:

[robh]

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