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
