That's what it does indeed. musachy
On 10/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Yes. But I am using Spring managed transactions that in my understanding > are outside of the struts Interceptor stack. > > My DAO's are annotated with the > org.springframework.transaction.annotation.Transactional annotation and > thus have their transactions managed as detailed here: > > http://static.springframework.org/spring/docs/2.0.x/reference/transaction.html > > I'm not an expert (I've only devoted a bit of time to studying the above > link), but it is my understanding that Spring wraps my DAO methods with > Aspects which control Transaction management (opening/closing). > > best, > > Jon French > Programmer > ASRC Management Services > ECOS Development Team > [EMAIL PROTECTED] > 970-226-9290 > > Fort Collins Science Center > US Geological Survey > 2150 Centre Ave, Building C > Fort Collins, CO 80526-8116 > > > > "Al Sutton" <[EMAIL PROTECTED]> > 10/02/2007 12:14 AM > Please respond to > "Struts Users Mailing List" <user@struts.apache.org> > > > To > "'Struts Users Mailing List'" <user@struts.apache.org> > cc > > Subject > RE: ModelDriven CRUD validation failure still causes JPA update - RESOLVED > > > > > > > Just a thought, are you actually using transactions? > > If so why not modify the interceptor to only commit if a SUCCESS is > returned > or perform a rollback if ERROR is returned from the action invocation. > > Al. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 02 October 2007 04:04 > To: Struts Users Mailing List > Subject: Re: ModelDriven CRUD validation failure still causes JPA update - > RESOLVED > > > OK: I've fixed the problem. > > I'm not sure why this was the case, but here is what was causing the > problem: > > In my ModelDriven action, I had a method like this: > > public Collection<ProjectType> getAllProjectTypes(){ > return this.projectTypeDao.getAll(); > } > > Notice that instead of returning a simple instance reference, this method > actually returned the result of a JPA query (via the DAO method call). > > This method was used by a struts 2 iterator tag to populate a select list > on the form and was thus called when my "input" JSP rendered after an > invalid request. > > I noticed that in the stack trace of my Oracle constraint violation, it > was actually this query call that was triggering the Session.flush() call > that was inappropriately saving the invalid entity state to the database. > By "pre-loading" the collection in the prepare() method like so: > > public void prepare() throws Exception { > .... > this.allProjectTypes = this.projectTypeDao.getAll(); > } > > public Collection<ProjectType> getAllProjectTypes(){ > return this.allProjectTypes; > } > > ... the problematic flush() goes away. > > Beats me why this matters. I'm sure a JPA guru could explain something > about the Transaction or EntityManager instance being different in the two > > cases, but I don't understand it yet. > > Jon French > Programmer > ASRC Management Services > ECOS Development Team > [EMAIL PROTECTED] > 970-226-9290 > > Fort Collins Science Center > US Geological Survey > 2150 Centre Ave, Building C > Fort Collins, CO 80526-8116 > > > > [EMAIL PROTECTED] > 10/01/2007 08:29 PM > Please respond to > "Struts Users Mailing List" <user@struts.apache.org> > > > To > "Struts Users Mailing List" <user@struts.apache.org> > cc > > Subject > Re: ModelDriven CRUD validation failure still causes JPA update > > > > > > > Unfortunately, it appears that xworks validation works not on the > ServletRequest parameters, but on the properties already set on the Action > > > - or in my case the model bean. So moving the interceptor up the stack > would just break validation. > > From the com.opensymphony.xwork2.validator.ValidationInterceptor javadoc: > > * This interceptor runs the action through the standard validation > framework, which in turn checks the action against > * any validation rules (found in files such as > <i>ActionClass-validation.xml</i>) and adds field-level and action-level > * error messages (provided that the action implements [EMAIL PROTECTED] > com.opensymphony.xwork2.ValidationAware}). This interceptor > * is often one of the last (or second to last) interceptors applied in a > stack, as it assumes that all values have > * already been set on the action. > > Thanks, > > Jon French > Programmer > ASRC Management Services > ECOS Development Team > [EMAIL PROTECTED] > 970-226-9290 > > Fort Collins Science Center > US Geological Survey > 2150 Centre Ave, Building C > Fort Collins, CO 80526-8116 > > > > Dave Newton <[EMAIL PROTECTED]> > 10/01/2007 04:42 PM > Please respond to > "Struts Users Mailing List" <user@struts.apache.org> > > > To > Struts Users Mailing List <user@struts.apache.org> > cc > > Subject > Re: ModelDriven CRUD validation failure still causes JPA update > > > > > > > --- [EMAIL PROTECTED] wrote: > > That's an interesting idea Dave. I'm using the paramsPrepareStack. > > It'll take some investigation to > > > see if that would fix the issue. > > Shouldn't take much; it might be as simple as adding a > validate/defaultWorkFlow up towards the top (although I might try just > adding new ones rather than removing the existing ones). > > > Fort Collins Science Center > > US Geological Survey > > 2150 Centre Ave, Building C > > I used to live up Poudre River Canyon (Poudre Park); I > sure miss the climbing out there :( > > d. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
