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
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
hibernate-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
