Yes, that was the issue, it was interceptor order related. Now if only I could get the persistent entity not to be flushed under specific conditions:
- Exception - Non-SUCCESS return code, etc. > -----Original Message----- > From: Chris Pratt [mailto:thechrispr...@gmail.com] > Sent: Wednesday, March 09, 2011 1:35 PM > To: Struts Users Mailing List > Subject: Re: Re : Re : ModelDriven & Hibernate Entities > > It might just be an order of interceptors problem. One of your first > interceptors should be your login check. That should definitely happen > before the standard paramsPrepareParamsStack is run. > (*Chris*) > > On Wed, Mar 9, 2011 at 11:04 AM, CRANFORD, CHRIS > <chris.cranf...@setech.com>wrote: > > > Francois - > > > > I use the standard paramsPrepareParamsStack interceptor from Struts. > > > > All I have done on my end is wrap this interceptor stack with a few > > application specific interceptors that control things such as > authentication > > required, auditing, and logging. I stepped upon my issue one day > when I had > > returned from lunch and my session had timed out. I hit the SAVE > button on > > a form and it redirected me to our login page. > > > > But prior to logging back in; I checked the database and noticed that > the > > record was in fact persisted with the changes from the form. All I > can > > gather is the following: > > > > 1. Request comes in for Struts > > 2. Hibernate Session opened via OSIV > > 3. Model is loaded from DB via prepare() > > 4. Struts copies parameters into the model > > 5. Validation/Interceptors fire > > 6. Authentication Interceptor detects timed out session, returns > LOGIN > > 7. User presented with login page > > 8. OSIV filter closes, changes from #4 persisted. > > > > I then created a simple test action where I load a persist entity > from the > > DB in a ModelDriven action, I call the action passing parameters that > are > > properties on the entity. Then the execute() method does nothing > more than > > return SUCCESS which maps to my /pages/done.jsp. The changes are > committed. > > > > I'd prefer that changes aren't committed unless I explicitly call to > do so > > on the EntityManager; however I understand Hibernate/JPA's reasons > behind > > why it works the way it does. > > > > > > > > > -----Original Message----- > > > From: François Rouxel [mailto:rouxe...@yahoo.com] > > > Sent: Wednesday, March 09, 2011 12:24 PM > > > To: Struts Users Mailing List > > > Subject: Re : Re : ModelDriven & Hibernate Entities > > > > > > Hi Chris, > > > first, > > > you might have another pb, because struts2 does not change your > model > > > if a > > > validation failed. In may case, the model is not changed so not > > > persisted. Do u > > > use validation and workflow interceptor ? > > > second, > > > you are right about MVC pattern, but, just be aware that when you > use > > > OSIV > > > pattern, hibernate call backend service when loading data...:-)) so > > > your JSP is > > > not just a view in that case.... > > > > > > > > > I wrote my first mail thinking you wanna rollback after an > exception > > > occured. > > > maybe it's gonna help others. > > > > > > fr/ > > > > > > > > > ____________________________________________ > > > ____________________________________________ > > > > > > > > > > > > ----- Message d'origine ---- > > > De : "CRANFORD, CHRIS" <chris.cranf...@setech.com> > > > À : Struts Users Mailing List <user@struts.apache.org> > > > Envoyé le : Mer 9 mars 2011, 13h 09min 33s > > > Objet : RE: Re : ModelDriven & Hibernate Entities > > > > > > Francois - > > > > > > While that may work for you, I wouldn't place anything Hibernate or > > > persistence > > > related in my JSP pages at all. In my mind, this breaks the entire > > > reasoning > > > behind MVC and the view simply there to render data. If the view > is > > > doing > > > anything beyond that, I have a design problem, but again that's my > > > opinion. > > > > > > But what about when you use the INPUT result code in your execute() > > > method. > > > > > > If I return the user to the INPUT method because maybe I'm not > using > > > the Struts > > > validation framework and doing it myself in my execute() method or > I > > > have some > > > complex conditions I must check for before I save the data. In > this > > > case, by > > > returning INPUT and setting some action field or error messages to > be > > > shown to > > > the user, the error exception handler isn't fired, thus your > rollback > > > isn't > > > fired either; leaving your entity persisted with likely dirty data. > > > > > > > -----Original Message----- > > > > From: François Rouxel [mailto:rouxe...@yahoo.com] > > > > Sent: Wednesday, March 09, 2011 11:43 AM > > > > To: Struts Users Mailing List > > > > Subject: Re : ModelDriven & Hibernate Entities > > > > > > > > same issue > > > > this how I fixed it : (the main idea is to redirect to a jsp if > an > > > > exception > > > > occured, and the jsp rollback) > > > > > > > > create an error page error.jsp > > > > <%@page import="com.rdvcentral.util.persistance.HibernateUtil"%> > > > > <%@ page contentType="text/html;charset=UTF-8" language="java" > %> > > > > <%@ taglib prefix="s" uri="/struts-tags" %> > > > > <%@ taglib prefix="sj" uri="/struts-jquery-tags" %> > > > > > > > > > > > > <%@page import="org.hibernate.Transaction"%> > > > > <%@page import="org.apache.log4j.Logger"%> > > > > > > > > <s:property value="%{logError(exception)}"/> > > > > <% > > > > Transaction tx = new > > > > > > > > HibernateUtil().getSessionFactory().getCurrentSession().getTransaction( > > > > ); > > > > if (tx != null && tx.isActive()) { > > > > tx.rollback(); > > > > } > > > > %> > > > > > > > > In your struts mapping file : > > > > > > > > <global-results> > > > > <result name="unhandledException">/error.jsp</result> > > > > </result> > > > > </global-results> > > > > > > > > <global-exception-mappings> > > > > <exception-mapping exception="java.lang.Exception" > > > > result="unhandledException" /> > > > > </global-exception-mappings> > > > > > > > > hope it will help you > > > > > > > > > > > > ____________________________________________ > > > > ____________________________________________ > > > > > > > > > > > > > > > > ----- Message d'origine ---- > > > > De : "CRANFORD, CHRIS" <chris.cranf...@setech.com> > > > > À : Struts Users Mailing List <user@struts.apache.org> > > > > Envoyé le : Mer 9 mars 2011, 12h 34min 32s > > > > Objet : ModelDriven & Hibernate Entities > > > > > > > > I had started down a path of using the ModelDriven interface from > > > > Struts > > > > because I find it really helps maintain a class action class > without > > > > large numbers of get/set methods for screens that contain a lot > of > > > form > > > > fields. > > > > > > > > However, I am finding at least with how I have attempted to > approach > > > > ModelDriven to have several drawbacks. For example, by using the > > > OSIV > > > > (Open Session In View) filter, I am finding that when Struts sets > the > > > > properties on the entity and afterward if an exception is thrown, > > > > caught > > > > and handled and doesn't trigger Hibernate to actually "rollback"; > the > > > > changes are persisted which leaves my entity in a dirty > inconsistent > > > > state. > > > > > > > > How have others solved this by using your entity domain POJOs in > your > > > > view? > > > > > > > > Do you use them detached from the session so that you explicitly > have > > > > to > > > > merge them to the session to be persisted? If so, how do you > deal > > > with > > > > multiple lazy loaded collections in your entity? > > > > > > > > Or would using DTO objects from my service layer a better > alternative > > > > to > > > > insure that no data is actually persisted to the database that > > > > shouldn't > > > > be? > > > > > > > > > > > > ----------------------------------------------------------------- > ---- > > > > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > > > > For additional commands, e-mail: user-h...@struts.apache.org > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------------- > ---- > > > > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > > > > For additional commands, e-mail: user-h...@struts.apache.org > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > -- > > > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > > > For additional commands, e-mail: user-h...@struts.apache.org > > > > > > > > > > > > > > > ------------------------------------------------------------------- > -- > > > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > > > For additional commands, e-mail: user-h...@struts.apache.org > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > > For additional commands, e-mail: user-h...@struts.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
