Tapernate looks very promising, but there some solutions to choose from. Honeycomb, HiveMind Utilities and Tapernate (and howards ePluribus project) should merge in to one solution for this tapestry+hibernate problem.
On 4/22/06, James Carman <[EMAIL PROTECTED]> wrote: > Oh, and all of that stuff is publicly available. The spring > transaction/hibernate support stuff is in a "hivemind" project at JavaForge > (I'm moving it to honeycomb soon). The only thing that I have put into my > own SVN repository is the "tapernate" stuff. But, I've talked to Howard > about putting that into the "tapestry" project at JavaForge as one of the > subprojects. > > -----Original Message----- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Hans L > Sent: Saturday, April 22, 2006 3:14 PM > To: tapestry-user@jakarta.apache.org > Subject: Re: tapestry/hibernate sessions & pageBeginRender() > > Hi James, > > James Carman wrote: > > Well, if you just store the Person object, you have to reattach it to the > > current session (which is what my code does). > > > > I don't want to store just the id in the session. You need to store the > > whole object to keep the version information (unless of course you don't > > need the optimistic locking stuff). You're not supposed to manually set > the > > version property on Hibernate-managed entities. Hibernate will do that. > > > > I don't use the classes in hivetranse or honeycomb. I have my own classes > > for dealing with all of this and they work for me. You're welcome to use > > it. It's all Apache v2.0 licensed. You can do all the transaction > > demarcation stuff and everything using the Spring syntax. The example > > application (tapernate-example) shows how it all works. I'm going to be > > adding my stuff to the honeycomb project once we figure out where it's > going > > to live (javaforge vs. sourceforge). > > I checked out your repository; this is *really* useful code for me -- > and answers all of the big questions I've had in trying to integrate > hibernate + tapestry. The property persistence strategy approach looks > to be the most elegant way to deal with the detached entities and I'm > going to figure out how to add that persistence strategy to my tapestry > setup on Monday. > > One quick question: is there a reason why your persistence solution > couldn't extend Spring's HibernateDaoSupport directly? Admittedly, I > haven't looked at the Hivemind HibernateService class that you're > extending, but it looks like the important part there is the > getSession() method, which I assume is the same as HibernateDaoSupport. > I haven't completely understood what Hivemind provides that Spring > doesn't (or vice versa), but for now I'm trying to keep my application > as simple as is feasible and trying to stick to one framework (Spring) > for the dependency injection / IoC. > > Thanks again for this contribution -- and I'm glad to hear that it's > going to be made more publicly available in the future. > > Thanks, > Hans > > > --------------------------------------------------------------------- > 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] > > -- /ted --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
