In case anyone is interested, I found this plug-in for the exact problem that look promising:
http://code.google.com/p/hibernatesession-plugin-for-struts2/ On Thu, Nov 13, 2008 at 3:46 PM, Adam Ruggles <[EMAIL PROTECTED]> wrote: > > Use a struts interceptor instead of a servlet filter. That way you can check > the return type of the action that gets executed and respond appropriately. > > > > Burton Rhodes wrote: >> >> I am having trouble getting Struts 2.x to implement validation and >> hibernate using the HibernateSessionRequestFilter (the pattern >> suggested on Hibernate.org). When the validation fails, Hibernate >> will still update the object in the database when the HibernateFilter >> closes the transaction. I get why this is happening, but I can't seem >> to find anyone who has really figured out an *elegant* solution. Any >> ideas? >> >> >> >> public class HibernateSessionRequestFilter implements Filter { >> >> static Logger log = >> Logger.getLogger(HibernateSessionRequestFilter.class); >> >> private SessionFactory sf; >> >> public void doFilter(ServletRequest request, >> ServletResponse response, >> FilterChain chain) >> throws IOException, ServletException { >> >> try { >> >> // This starts the Hibernate transaction >> sf.getCurrentSession().beginTransaction(); >> >> // Call the next filter (continue request processing) >> chain.doFilter(request, response); >> >> // Commit and cleanup >> sf.getCurrentSession().getTransaction().commit(); <---- >> ********* Data is written here no matter what ************ >> >> } catch (StaleObjectStateException staleEx) { >> log.fatal("This interceptor does not implement optimistic >> concurrency control!"); >> log.fatal("Your application will not work until you add >> compensation actions!"); >> // Rollback, close everything, possibly compensate for any >> permanent changes >> // during the conversation, and finally restart business >> conversation. Maybe >> // give the user of the application a chance to merge some >> of his work with >> // fresh data... what you do here depends on your >> applications design. >> throw staleEx; >> >> } >> // This is a catch-all catch, define other Exceptions here >> catch (Throwable ex) { >> // Rollback only >> ex.printStackTrace(); >> try { >> if (sf.getCurrentSession().getTransaction().isActive()) { >> log.fatal("Trying to rollback database transaction >> after exception"); >> sf.getCurrentSession().getTransaction().rollback(); >> } >> } catch (Throwable rbEx) { >> log.fatal("Could not rollback transaction after exception!", >> rbEx); >> } >> >> // Let others handle it... maybe another interceptor for >> exceptions? >> throw new ServletException(ex); >> } >> } >> >> public void init(FilterConfig filterConfig) throws ServletException { >> log.trace("Initializing filter..."); >> log.trace("Obtaining SessionFactory from static HibernateUtil >> singleton..."); >> sf = HibernateUtil.getSessionFactory(); >> } >> >> public void destroy() {} >> >> } >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > -- > View this message in context: > http://www.nabble.com/Using-validation-with-Hibernate...-tp20488996p20490241.html > Sent from the Struts - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > 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]
