@Configurable does not seem to be aware of ApplicationContextAware

[geirhe]

I have been using a custom built hibernate interceptor for some time to inject domain models with dependencies. A nice side-effect of that interceptor is that the marker interfaces present in Spring are taken care of at the same time.

I have rewritten my application to using @configurable and aspectj load-time weaving. All I am getting is dependency injection. (And a considerable delay when launching my tests)

I am wondering if this is an oversight? Is there a way of handling this that I just haven't seen? Is there an @ApplicationContextAware annotation somewhere that I haven't found?

[Rod Johnson]

You will get only autowiring of bean properties. There is no out of the box functionality to apply ApplicationContextAware, but it would be fairly straightforward to build in your own aspect...

[nlif]

I have also been using my own Hibernate interceptor, which simply uses the AutowireCapableBeanFactory.applyBeanPropertyValues () method to wire domain objects. When Spring 2.0 become available, and I saw there is built-in feature for this, I though I should replace my own code with the framework feature. As a rule of thumb, I always prefer to use framework built-in mechanisms over writing my own. However, I'd like to know the pros and cons of using the AspectJ approach before making the switch. After all, my code is working, and as they say "if it's ain't broken, don't fix it"

I'd appreciate any insights - performance implications, reliablity, introducing yet another technological dependency, ease of configuration etc.

Thanks,
Naaman

[geirhe]

I'd appreciate any insights - performance implications, reliablity, introducing yet another technological dependency, ease of configuration etc.

Well, you should come to Javazone in Oslo on the 14. :-)

Short story: I have tried it, but I had to remove it again. I have tests that involve loading Spring and Hibernate, and I went from a 14 second to a 53 second start up time.

Since a developer typically runs tests somewhere between 10 and 100 times a day, these seconds add up. Having a 1-minute start up time for running a test also breaks "flow". Breaking flow is harder to quantify, but I am sure the cost is much higher than the 53 seconds.

Our old solution works quite well, so we are still using that.