Annotating @Transactional on the action didn't help. > -----Original Message----- > From: Maurizio Cucchiara [mailto:maurizio.cucchi...@gmail.com] > Sent: Thursday, March 10, 2011 1:41 AM > To: Struts Users Mailing List > Cc: CRANFORD, CHRIS > Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities > > It's exactly what I meant (you can leave in your service class too). > The object factory must be spring and your class name inside the > action configuration must contain the bean id (instead of the real > class name). > I'm not sure if it works but it worth a try though. > > On 10 March 2011 00:08, CRANFORD, CHRIS <chris.cranf...@setech.com> > wrote: > > In the Struts2 Action rather than my service class? > > > >> -----Original Message----- > >> From: Maurizio Cucchiara [mailto:maurizio.cucchi...@gmail.com] > >> Sent: Wednesday, March 09, 2011 4:20 PM > >> To: Struts Users Mailing List > >> Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities > >> > >> Have you tried to put the transational annotation in the class > >> declaration? > >> > >> Maurizio Cucchiara > >> > >> Il giorno 09/mar/2011 21.38, "CRANFORD, CHRIS" > >> <chris.cranf...@setech.com> > >> ha scritto: > >> > 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 > >> > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > > For additional commands, e-mail: user-h...@struts.apache.org > > > > > > > > -- > Maurizio Cucchiara
--------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
