Okay, folks. I've abstracted out the Hibernate/Tapestry stuff into its own project called "Tapernate." You can download the source and build it yourself (the libs are there for you) from SVN:
http://www.carmanconsulting.com/svn/public/tapernate/trunk All you have to do to get this stuff working is add the following things to your hivemodule.xml file... 1. Hibernate configuration (of course you'd use your own entity classes and your own dialect and add other properties, etc.)... <contribution configuration-id="tapernate.HibernateSettings"> <mapping class="com.myco.domain.entity.Account"/> <property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect"/> </contribution> 2. If you want to use the "EntitySqueezer" (you'll have to comment it out of Tapernate's hivemodule.xml file and re-build if you don't)... <contribution configuration-id="tapernate.DataClasses"> <data-class>com.myco.domain.entity.AbstractEntity</data-class> </contribution> Here, AbstractEntity is a common superclass for all of your entities (most people do that for Hibernate). 3. You can have your DAOs extends com.carmanconsulting.tapernate.hibernate.HibernateService and they will automatically have the Session injected into them. 4. Tapernate implements the "OpenSessionInView Pattern" automatically, so you don't have to worry about that. Now, this stuff is supplied as-is with no warranty or guarantees. Of course, if you guys find something wrong with it, I'll fix it because I'm using it in my own project. Enjoy! -----Original Message----- From: Anthony Fox [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 22, 2006 12:43 PM To: Tapestry users Subject: Re: hibernate detached objects as persistent page properties I have considered a similar solution as I use Spring as well. However, I was looking for a way to not have to _explicitly_ reattach objects. Rather, I would like all persistent detached objects in the session's context to reattach automatically. A filter or interceptor with knowledge of what objects are hibernate detached objects and reattached them automatically would be ideal. This would ease further development as adding new persistent properties to pages wouldn't need the additional step of adding these properties to the list of properties to reattach at pageRender time. Have you considered or seen a solution like the one I have described? On 2/22/06, Shawn Church <[EMAIL PROTECTED]> wrote: > I'm doing this in several applications. I normally use Spring also, but > that is not really necessary. Tapestry isn't aware of the persistence > implementation, but it does have to explicitly attach (and occasionally > merge or evict) detached objects. Since I reference my DAO services in > my Tapestry pages already, it seemed appropriate to create a > "HibernateService" and "HibernateLegacyService" (I probably should have > named them something more generic) with public methods supporting > attach, merge, and evict. I have to support multiple, unrelated > databases, hence the multiple session-management implementations. I > only attach in pageBeginRender, although I occasionally have to merge or > evict in my form listener. > > I believe Tapestry is best suited to working with detached objects (and > this method is one which is recommended by the Hibernate team), rather > than storing IDs and reloading. In my case especially where I have a > lot of composite keys, passing IDs around would be a hack. Having the > detached object available to Tapestry makes it very nice and seamless > when I need access to collections or other objects within that object. > > I don't experience lazy initialization exceptions any more (unless I've > done something really wrong), but NonUniqueObjectExceptions can creep in > if for example I try to load an object which happens to already have > been loaded within the same session within a collection of a parent > object. This is again often the result of me doing something stupid, > but there a few (rare in my case) legitimate instances where this is > needed. In this case, I take care to first evict (or merge if > appropriate) the duplicate object. > > Shawn > > Quoting Anthony Fox <[EMAIL PROTECTED]>: > > > Hi, > > > > I have an application that has a lot of hibernate detached objects > > (with lazy loaded collections) that are persistent page properties. > > What are best practices for reattaching these detached objects while > > maintaining a clean separation of layers? I have my implementation > > specific persistence layer separated into DAOs, a service layer, and > > the tapestry ui layer. I would like to keep tapestry independent of > > the persistence layer. I am using the OpenSessionInView pattern to > > open a new hibernate session for each web request. However, I can't > > determine a clean way to reattach all the hibernate detached objects > > at the beginning of each web request. I've noticed that some people > > use pageBeginRender() to reattach objects, but I don't want to > > expose > > my tapestry code to the persistence implementation. An interceptor > > or > > filter or something that separated the ui layer from being aware of > > the persistence layer would be ideal. How have others dealt with > > this > > issue? > > > > Thanks, > > Anthony > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
