You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Jo...@fws.gov on 2007/10/02 05:04:08 UTC
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" <us...@struts.apache.org>
To
"Struts Users Mailing List" <us...@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 {@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 <ne...@yahoo.com>
10/01/2007 04:42 PM
Please respond to
"Struts Users Mailing List" <us...@struts.apache.org>
To
Struts Users Mailing List <us...@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
RE: Calling struts 2 actions
Posted by Henry Park <hs...@hotmail.com>.
I found a site that explains a similar problem:
http://www.nabble.com/-s2--no-result-defined-error-after-failed-validation---can-someone-help--t4030311.html
My problem is also trying to find an 'input' method. I have not even defined an input method but it is still looking for it. I tried the 'clearErrorsAndMessages();' function but that did not help.
Henry> From: hspark182@hotmail.com> To: user@struts.apache.org> Subject: Calling struts 2 actions> Date: Tue, 2 Oct 2007 10:16:14 -0700> > > Consider the following segment from my struts.xml:> > <action name="Item" class="action.ItemAction">> <result name="input">/jsp/items/itemEntry.jsp</result>> <result name="success">/jsp/items/itemView.jsp</result> > <result name="error">/jsp/error.jsp</result> > </action>> > What could be the cause for an action call not calling the correct method? > > I have a link on 'itemView.jsp' that points to Item!view.action. When I click the link, it opens up the 'itemEntry.jsp'. However, when I manually put the 'Item!view.action' in my browser's address bar it returns the correct page. What could be causing this?> _________________________________________________________________> Peek-a-boo FREE Tricks & Treats for You!> http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us
_________________________________________________________________
Help yourself to FREE treats served up daily at the Messenger Café. Stop by today.
http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline
Calling struts 2 actions
Posted by Henry Park <hs...@hotmail.com>.
Consider the following segment from my struts.xml:
<action name="Item" class="action.ItemAction">
<result name="input">/jsp/items/itemEntry.jsp</result>
<result name="success">/jsp/items/itemView.jsp</result>
<result name="error">/jsp/error.jsp</result>
</action>
What could be the cause for an action call not calling the correct method?
I have a link on 'itemView.jsp' that points to Item!view.action. When I click the link, it opens up the 'itemEntry.jsp'. However, when I manually put the 'Item!view.action' in my browser's address bar it returns the correct page. What could be causing this?
_________________________________________________________________
Peek-a-boo FREE Tricks & Treats for You!
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us
RE: ModelDriven CRUD validation failure still causes JPA update -
RESOLVED
Posted by "Tobias M." <to...@bigfoot.de>.
Hi Fabiano,
first of all thank you for your valuable hint. I established an interceptor
CommitAwareInterceptor at the top of the interceptor stack. This interceptor
is tagging the JPA transaction for RollbackOnly in case of
a.) the action is not implementing CommitAware
b.) the action is implementing CommitAware and the action's
implementation of isCommitable() is returning false.
These checks are performed at the latest step of of the request processing.
This implies that the view is rendered using the old model values i.e. the
old and maybe invalid model state. Every lazy loading is still working at
rendering time.
The only thing the OSIV-Filter has to do is to evaluate the transactions
RollbackOnly-Flag and commit accordingly.
And voila, everything is working fine. Perfect control over the transaction,
no invalid values on the database and no unwanted commits regarding to a.)
Once again, thanks for your hint,
Tobias
Fabiano Franz wrote:
>
> 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://literar.org
> http://pribi.com.br
>
>
--
View this message in context: http://www.nabble.com/ModelDriven-CRUD-validation-failure-still-causes-JPA-update-tp12987242p21062748.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
RE: ModelDriven CRUD validation failure still causes JPA update -
RESOLVED
Posted by Fabiano Franz <co...@fabianofranz.com>.
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...@alsutton.com>
>> 10/02/2007 12:14 AM
>> Please respond to
>> "Struts Users Mailing List" <us...@struts.apache.org>
>>
>>
>> To
>> "'Struts Users Mailing List'" <us...@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" <us...@struts.apache.org>
>>
>>
>> To
>> "Struts Users Mailing List" <us...@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 <ne...@yahoo.com>
>> 10/01/2007 04:42 PM
>> Please respond to
>> "Struts Users Mailing List" <us...@struts.apache.org>
>>
>>
>> To
>> Struts Users Mailing List <us...@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
RE: ModelDriven CRUD validation failure still causes JPA update -
RESOLVED
Posted by cilquirm <aa...@gmail.com>.
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...@alsutton.com>
> 10/02/2007 12:14 AM
> Please respond to
> "Struts Users Mailing List" <us...@struts.apache.org>
>
>
> To
> "'Struts Users Mailing List'" <us...@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" <us...@struts.apache.org>
>
>
> To
> "Struts Users Mailing List" <us...@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 <ne...@yahoo.com>
> 10/01/2007 04:42 PM
> Please respond to
> "Struts Users Mailing List" <us...@struts.apache.org>
>
>
> To
> Struts Users Mailing List <us...@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-tf4550890.html#a13002700
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
Re: ModelDriven CRUD validation failure still causes JPA update - RESOLVED
Posted by Musachy Barroso <mu...@gmail.com>.
That's what it does indeed.
musachy
On 10/2/07, Jon_French@fws.gov <Jo...@fws.gov> 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...@alsutton.com>
> 10/02/2007 12:14 AM
> Please respond to
> "Struts Users Mailing List" <us...@struts.apache.org>
>
>
> To
> "'Struts Users Mailing List'" <us...@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" <us...@struts.apache.org>
>
>
> To
> "Struts Users Mailing List" <us...@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 {@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 <ne...@yahoo.com>
> 10/01/2007 04:42 PM
> Please respond to
> "Struts Users Mailing List" <us...@struts.apache.org>
>
>
> To
> Struts Users Mailing List <us...@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
>
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: ModelDriven CRUD validation failure still causes JPA update - RESOLVED
Posted by Jo...@fws.gov.
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...@alsutton.com>
10/02/2007 12:14 AM
Please respond to
"Struts Users Mailing List" <us...@struts.apache.org>
To
"'Struts Users Mailing List'" <us...@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" <us...@struts.apache.org>
To
"Struts Users Mailing List" <us...@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 {@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 <ne...@yahoo.com>
10/01/2007 04:42 PM
Please respond to
"Struts Users Mailing List" <us...@struts.apache.org>
To
Struts Users Mailing List <us...@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
RE: ModelDriven CRUD validation failure still causes JPA update - RESOLVED
Posted by Al Sutton <al...@alsutton.com>.
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" <us...@struts.apache.org>
To
"Struts Users Mailing List" <us...@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 {@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 <ne...@yahoo.com>
10/01/2007 04:42 PM
Please respond to
"Struts Users Mailing List" <us...@struts.apache.org>
To
Struts Users Mailing List <us...@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