Why Do Tapestry and Hibernate Fight So Much?

April 22, 2006 - 2 minute read -

I've been away from doing much Java development recently. I've been getting paid to do .NET development and have been doing Ruby in my free time. So, I've been looking forward to get back to some Java programming (which was the first language I ever got paid to develop).

I've recently been looking into an application that is using Spring, Tapestry and Hibernate. These are three very widely used frameworks. And they are often used together . . . so why is it that basic things like Lazy Loading in Hibernate are totally broken when you use Tapestry?

Sure you can use an Open Session In View servlet filter and that solves like 10% of the problem. But Tapestry serializes Objects into the page, stores some in the session and in general seems to create them and pass them around out of thin air. Well, when a Hibernate Object becomes detached from a Hibernate Session, you can no longer Lazy Load its child collections. There also seems to be no easy way to get hold of all of the Objects that might be used in the creation of a Page. You can subclass the Engine and get some items from the user's Session, you can Subclass the BasePage and find the properties of the Page and reattach those to the Hibernate Session. Great and then you only have to deal with the Objects that are passed between pages in other mysterious ways. Oh, and don't let it bother you that if an Object is re-instantiated with the same ID of an Object already in the Hibernate Session then you can't reattach it to the session.

And we call this an improvement?

Either this application is doing something totally crazy with Tapestry or just don't bother with this combination if you want to do anything that resembles a complex application with separate layers. The combination of Spring an Hibernate seem to work very well together and provide with a really strong framework on which to build an application. Tapestry though . . . I'm not yet sold.