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 > >
