Based on posts and various information posted by Juergen on the Hibernate site, I have been looking into re-architecting our domain access layer to utilize the Spring framework. I have posted some questions/concerns over on their forums, but that list is pretty unresponsive. So I was hoping to get a response here.

Is anyone using this type of setup extensively? The main concern I have is the fact the using the built in functionality the thread local session is only available during execution of the DAO methods. My typical usage is to obtain a domain entity through a DAO and then pass it to an "assembler" to build a DTO representation. But using the Spring setup, the session would be closed by the time the assembler is called.

To complicate this even further, I use session ejbs; and it is these session ejbs which coordinate the interaction between the DAO and the assembler. So there is not a way for me to introduce a HibernateInterceptor aspect to those methods. About the only thing I could do would be to somehow "prime" the thread local with a session from the ejb method prior to beginning the functionality.

The only other option I could come up with was to move the functionality performed by the ejbs into another seperate POJO class to which the ejb could delegate calls. This POJO could then be aspected with the HibernateInterceptor. But this seems like an awful lot of additional work for what seems like a minimal gain.

Anyone run into this issue and have a nice elegant solution?

Probably not useful, but what you said is that there is ONE EJB Session call which coordonate DAOs and assembler. You did not say that the DAO and assembler are coordinated by more than ONE EJB session call.
Because if so, 2 EJB Sessions = 2 threads = 2 thread local contexts = 2 hibernate sessions

Don't quite see the relevance. Whether it is 1 EJB call or 20, the issue is the same.

Session bean method obtains a DAO and calls a method to retreive an entity. Spring closes the Hibernate session as soon as the DAO method call returns. Now the session bean method makes a call into the assembler to build a DTO representation of the just loaded entity. Whoops, entity has lazy references and the session which loaded the lazy references is now closed = LazyInitializationException...

FWIW...

I started implementing a small slice of the system using a seperate "delegate" to the session ejb which is intercepted via spring much like the DAOs. Seems to be going OK so far

Agreed my answer was kind of stupid (happend some times ;-))

I use a similar architecture (ejb delegating to a POJO class).
The solution I found is code generation :
- generate EJB Session from tags in an Interface or in your POJO process class (Inteface implemented by EJBBean and POJO)
- or generate EJB, etc from an XML file.

Best advantages I see in delegation to POJO design is that you're free to use EJB, Direct access, Access via a transaction management layer, (even) Web Service frontal layer just by adding new generation tags.