struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fabiano Franz <cont...@fabianofranz.com>
Subject RE: ModelDriven CRUD validation failure still causes JPA update - RESOLVED
Date Mon, 10 Mar 2008 21:37:27 GMT

I had the same issue regarding Struts 2 validations and Hibernate/JPA flush.
My solution:

Write an XWork Interceptor that is placed right after the validation
interceptor on your stack. This interceptor checks the actionErrors and
fieldErrors and, if any of them is not empty, performs a Hibernate/JPA
session clear.

Best regards,

Fabiano Franz
http://fabianofranz.com http://fabianofranz.com 
http://literar.org http://literar.org 
http://pribi.com.br http://pribi.com.br 
 



cilquirm wrote:
> 
> You can throw an exception , which you can specify in your 
> 
> @Transactional( rollbackFor = )
> 
> to have it rollback.
> 
> 
> 
> jon_french 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
>> jon_french@fws.gov
>> 970-226-9290
>> 
>> Fort Collins Science Center
>> US Geological Survey
>> 2150 Centre Ave, Building C
>> Fort Collins, CO 80526-8116
>> 
>> 
>> 
>> "Al Sutton" <al.sutton@alsutton.com> 
>> 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: Jon_French@fws.gov [mailto:Jon_French@fws.gov] 
>> 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
>> jon_french@fws.gov
>> 970-226-9290
>> 
>> Fort Collins Science Center
>> US Geological Survey
>> 2150 Centre Ave, Building C
>> Fort Collins, CO 80526-8116
>> 
>> 
>> 
>> Jon_French@fws.gov 
>> 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 
>> ActionClass-validation.xml) and adds field-level and action-level
>>  * error messages (provided that the action implements {@link 
>> 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
>> jon_french@fws.gov
>> 970-226-9290
>> 
>> Fort Collins Science Center
>> US Geological Survey
>> 2150 Centre Ave, Building C
>> Fort Collins, CO 80526-8116
>> 
>> 
>> 
>> Dave Newton <newton.dave@yahoo.com> 
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> --- Jon_French@fws.gov 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: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>> 
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>> 
>> 
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/ModelDriven-CRUD-validation-failure-still-causes-JPA-update-tp12987242p15958581.html
Sent from the Struts - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message