I still think this is related to my @Transactional annotation maybe. > -----Original Message----- > From: Dave Newton [mailto:davelnew...@gmail.com] > Sent: Wednesday, March 09, 2011 2:16 PM > To: Struts Users Mailing List > Subject: Re: Re : Re : ModelDriven & Hibernate Entities > > Another reason OSiV filters can be tricky. > > Dave > > On Wed, Mar 9, 2011 at 2:04 PM, 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 >
--------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
