[Springframework-developer] Hibernate & Spring Javabean instantiation

[Rob B. <rob...@ve...>]

I have posted this to the Hibernate & Spring mailing lists as I think this will require the involvement of both development teams to answer.

Hibernate uses **javabean no-arg constructors** to instantiate objects and then uses javabean setters / getters when mapping from / to the database.

Spring uses javabean no-arg constructors to instantiate objects and then uses javabean setters to "configure" the objects.  Optionally, Spring can then call BeanFactoryAware.setBeanFactory for "Bean Factory Aware beans" and InitializingBean.afterPropertiesSet to inform the object it is fully configured if it has setup work to do.

This is all good, but what if I have an object that needs to be configured via spring, but needs to be persisted  via Hibernate?  Initially if I obtain the object from Spring via context.getBean("bean-name") the bean will have been instantiated and configured via Spring, and persisting the object via Hibernate should work fine.  However, if I then retrieve the object from the DB via Hibernate the Spring bean factories are by-passed because Hibernte uses the javabean no-arg constructors directly, and not the spring bean factories.

This could be a problem if:

1) Some attributes of the javabean were not persisted in the DB, but should be loaded from the Spring config when the object is re-instantiated.  Business rules are the best example of this - Think of range limitations like a number must be between 5 and 15 - then the business changes the rules and the number must now be between 3 and 15, or 8 and 15. 

This may also require the business rules to be re-checked after the object is loaded by Hibernate.  Does Hibernate support any "after load" method calls to the object so it can perform this kind of task?  Could one be added?  It would be possible to call an "after load" method from within the DAO code the app developer must write, but it would not be possible to have the app do this on collections if we are using Hibernates lazy load features.

2) The javabean needs to be "BeanFactoryAware" and have the setBeanFactory method called.
3) The javabean relies on having the spring InitializingBean.afterPropertiesSet method called.


Both #2 and #3 should happen BEFORE any "after load" Hibernate method call, because those resources may be needed during the Hibernate call.

I think that adding support for this use case will probably require changes to Hibernate for it to support not only the javabean no-arg constructor, but also the spring bean factory method of object instantiation.  Better yet, to be more generic Hibernate should support the use of user defined "factory" methods.  Then Spring should provide a "Hibernate factory" that Hibernate could use to load any object from the Spring bean factory.  Providing this capability along with the Hibernate "after load" method call would allow for better "Idiomatic" java persistence.

Another option may be for Spring to have some sort of a way for a javabean no-arg constructor to call a "configure me" method.  I.E. the no-arg constructor could have code within it that calls Spring, and Spring configures the object using javabean setters, calls BeanFactoryAware.setBeanFactory and InitializingBean.afterPropertiesSet (if appropriate).  This is probably not a good option as it would be impossible to have two instances of the object that are configured differently.  Also, it's probably not possible / easy to do.

Or did I completely miss something and this already possible?
Thoughts?

Later
Rob