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/01 22:31:10 UTC
ModelDriven CRUD validation failure still causes JPA update
I have a ModelDriven action which controls CRUD operations on JPA managed
Entity E. E has a property called ?name? which maps to a database column
with a NOT NULL constraint. I have added a RequiredStringValidator
annotation to my Action to validate that the ?model.name? property is
non-null. The validation works perfectly.
However, during Struts Interceptor processing of a user entered empty
string for the ?model.name? ServletRequest parameter, entity instance E
has its getName() property set to a null value. Hibernate (my JPA
implementation provider) detects this property state change when the
Hibernate session is flushed at the closing of the JPA EntityManager by
the configured OpenEntityManagerInView ServletFilter. This results in an
attempt by Hibernate to update the ?name? database column to null and
results in a SqlException.
So the problem is that even with appropriate validation on a ModelDriven
action, my Entity moves to an invalid state which Hibernate then tries to
persist to the database at the closing of the session.
Based on what I gleaned from this WebWorkx post:
http://forums.opensymphony.com/thread.jspa?messageID=5315ᓃ
(which seems to be the exact same problem except with the
OpenSessionInView filter instead of my OpenEntityManagerInView filter)
And this spring post:
http://forum.springframework.org/showthread.php?t=35740
? I think that what I need to do is set Hibernate?s flush mode to NEVER.
What this means to me is that Hibernate will only flush when I execute a
EntityManager.flush() command and that OpenEntityManagerInView?s closing
of the EntityManager won?t automatically result in a Hibernate session
flush and thus Entity E?s invalid state will not be persisted. This is in
line with what I understand to be the default behavior of Spring?s
OpenSessionInView filter. Unfortunately, I have not yet been able to set
Hibernate's flush mode (nor am I certain that this will solve my issue).
Can anyone shed some light on this problem?
Thanks in advance!
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
Re: ModelDriven CRUD validation failure still causes JPA update
Posted by Musachy Barroso <mu...@gmail.com>.
> * instantiate a temporary bean used for the form only:
> BeanUtils.copyProperties(tempBean, yourBean);
>
That's what I do.
musachy
--
"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
Posted by Jo...@fws.gov.
Thanks Piero:
* don't flush the session and destroy the object
This is exactly what I want to do. However, the Hibernate session
automatically flushes when the EntityManager is closed during the
OpenEntityManagerInView filter exit filter operation. I definitely need
the filter in place to lazy load collections in my view pages.
* instantiate a temporary bean used for the form only:
BeanUtils.copyProperties(tempBean, yourBean);
Yes, but I'm reluctant to use this work-around although I admit that it
would probably work. IMO, the beauty of the ModelDriven pattern is that
you don't have to do this copy but can rather cut out the old Struts 1
ActionForm "middle-man" bean and do direct updates to your business
objects. Everything works great except this one problem with a validation
failure inappropriately triggering a database update.
* manage your entities with JPA's EntityManager, merge them manually.
I do. In fact, if the validation does NOT fail, my ModelDriven action
calls a JPA backed DAO that does update the entity with a
EntityManager.merge(...) call. In the case of failed validation, this DAO
is never invoked, but rather Hibernate automatically "merges" the invalid
Entity changes to the database when the Hibernate Session is closed.
Thanks for you help,
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
Piero Sartini <li...@pierosartini.de>
10/01/2007 03:38 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
> Since my Model is acquired from the Hibernate session (during the
> "prepare()" Action method), it is a transactional persistent instance.
> Note this from the hibernate documentation:
>
> "Transactional persistent instances (ie. objects loaded, saved, created
or
> queried by the Session) may be manipulated by the application and any
> changes to persistent state will be persisted when the Session is
flushed
> (discussed later in this chapter). There is no need to call a particular
> method (like update(), which has a different purpose) to make your
> modifications persistent."
I do not know hibernate but you could try the following solutions:
* don't flush the session and destroy the object
* instantiate a temporary bean used for the form only:
BeanUtils.copyProperties(tempBean, yourBean);
* manage your entities with JPA's EntityManager, merge them manually.
Piero
---------------------------------------------------------------------
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
Posted by Piero Sartini <li...@pierosartini.de>.
> Since my Model is acquired from the Hibernate session (during the
> "prepare()" Action method), it is a transactional persistent instance.
> Note this from the hibernate documentation:
>
> "Transactional persistent instances (ie. objects loaded, saved, created or
> queried by the Session) may be manipulated by the application and any
> changes to persistent state will be persisted when the Session is flushed
> (discussed later in this chapter). There is no need to call a particular
> method (like update(), which has a different purpose) to make your
> modifications persistent."
I do not know hibernate but you could try the following solutions:
* don't flush the session and destroy the object
* instantiate a temporary bean used for the form only:
BeanUtils.copyProperties(tempBean, yourBean);
* manage your entities with JPA's EntityManager, merge them manually.
Piero
---------------------------------------------------------------------
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
wierd problem
Posted by Henry Park <hs...@hotmail.com>.
I am having a wierd problem where my action calls are not forwarding to the correct page. Actually it works one time, but when I try to run the same action again (this time on the same page) it attempts to go to a different action (i.e. INPUT). Here is how I have it set up:
struts.xml:
<action name="ItemList" class="action.ItemAction" method="list">
<result name="success">/jsp/items.jsp</result>
</action>
<action name="Item" class="action.ItemAction" method="view">
<result name="input">/jsp/itemEdit.jsp</result>
<result name="success">/jsp/itemView.jsp</result>
</action>
items.jsp:
<s:form method="post" theme="simple" name="theForm">
<s:iterator value="resultList" status="status">
<a onClick=retrieveURL('<%= request.getContextPath() %>/Item!view.action?someBean.itemId=<s:property value="item_id"/>', main_span, null, "POST");>
<s:property value="item_details"/><br>
</a>
</s:iterator>
</s:form>
itemView.jsp:
<script language='javascript'>
function sort() {
... sorting code ...
retrieveURL("<%= request.getContextPath() %>/Item!view.action", main_target, "POST");
}
function retrieveURL(url, target, postMethod) {
try {
var params = Form.serialize($('theForm'));
} catch (e) {
var params = "";
}
new Ajax.Request(url,
{
method:postMethod,
parameters:params,
postBody:params,
onSuccess: function(transport) {
var response = transport.responseText;
target.innerHTML = response;
},
onLoading: function() {
showLoader(true);
},
});
}
</script>
<s:form method="post" theme="simple" name="theForm">
<s:hidden name="someBean.itemId" value="%{someBean.itemId}" />
<s:hidden name="someBean.sortColumn" value="%{someBean.sortColumn}" />
<s:hidden name="someBean.sortDirection" value="%{someBean.sortDirection}" />
<s:property value="%{someBean.itemId}"/><br>
<s:property value="%{someBean.itemName}"/><br>
<s:property value="%{someBean.itemDescription}"/><br>
<hr>
<input type='button' onClick='sort("actual");' value='Sort'/>
<s:iterator value="AssociatedItemList" status="status">
<s:property value="dateRange"/> - <s:property value="actual"/> - <s:property value="target"/><br>
</s:iterator>
So on 'items.jsp' I click on a line item and it successfully forwards to the 'success' page. However, on the details screen when click on 'sort', it calls the same action but does not return to the same page.
_________________________________________________________________
Connect to the next generation of MSN MessengerÂ
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline
Re: ModelDriven CRUD validation failure still causes JPA update
Posted by Jo...@fws.gov.
Yes. It is my understanding the that Hibernate FlushMode MANUAL or NEVER
(deprecated) instructs Hibernate to only flush the session when explitly
instructed to do so. In my case, I assume this means on a call to
EntityManager.flush().
By default, the mode seems to be set to AUTO. I've tried unsuccessfully,
through the PersitenceProperty notation, via persistence.xml, and the
jpaPropertyMap property of the spring
LocalContainerEntityManagerFactoryBean to set the
"org.hibernate.flushMode" property to "MANUAL". It was my hope that if I
could instruct Hibernate to use a MANUAL flush mode, then it wouldn't
flush upon session.close().
However, I've been unsuccessful in setting the flushMode thus far. I'm
going to try rebuilding the hibernate-entitymanager-3.3.1GA package with
the FlushMode set to MANUAL just to see if I can get the result I want.
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
"Musachy Barroso" <mu...@gmail.com>
10/01/2007 08:21 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
Only difference is that I don't use model driven. Is there any setting
to tell hibernate to flush the session when closed or it does that by
default?
musachy
On 10/1/07, Jon_French@fws.gov <Jo...@fws.gov> wrote:
> Yes, musachy. I do something very similar. Here is my prepare() method:
>
> public void prepare() throws Exception {
> if( this.id==0 ) {
> this.entity = new Entity();
> } else {
> this.entity = this.entityDao.findById(this.id);
> }
> }
>
> Here is the (obvious) getModel():
>
> public Object getModel() {
> return this.entity;
> }
>
> Here is the update, "execute()" method that is called upon form
> submission:
>
> @Validations(
> requiredStrings =
> {@RequiredStringValidator(fieldName = "model.name",
> message = "You must enter a title.")}
> )
> public String update() {
> if( this.id==0 ) {
> this.entityDao.create(this.entity);
> } else {
> this.entity.update(this.entity);
> }
> return SUCCESS;
> }
>
> So when a user enters a blank "model.name" field, this.entity.name
> property gets set to null, the update() method never is called, but
> Hibernate tries to write the update to the database when
> OpenEntityManagerInViewFilter closes the EntityManager:
>
> Here is the relevant code from OpenEntityManagerInViewFilter
>
> protected void doFilterInternal(
> HttpServletRequest request, HttpServletResponse
> response, FilterChain filterChain)
> throws ServletException, IOException {
>
> ...
>
> try {
> filterChain.doFilter(request, response);
> }
>
> finally {
> if (!participate) {
> EntityManagerHolder emHolder =
> (EntityManagerHolder)
> TransactionSynchronizationManager.unbindResource(emf);
> emHolder.getEntityManager().close();
> }
> }
> }
>
> 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
>
>
>
> "Musachy Barroso" <mu...@gmail.com>
> 10/01/2007 05:10 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
>
>
>
>
>
>
> I only use the beanutils.copy solution on a few places, on the other
> cases I always load the object model on the prepare() method if the
> "id" field is set (editing), and then call update or create on the
> entity manager in my action method. I never got that problem so I'm
> wondering what is different. (I use JPA on top of hibernate)
>
> musachy
>
> On 10/1/07, Dave Newton <ne...@yahoo.com> wrote:
> > --- 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
> >
> >
>
>
> --
> "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
>
>
>
--
"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
Posted by Musachy Barroso <mu...@gmail.com>.
Only difference is that I don't use model driven. Is there any setting
to tell hibernate to flush the session when closed or it does that by
default?
musachy
On 10/1/07, Jon_French@fws.gov <Jo...@fws.gov> wrote:
> Yes, musachy. I do something very similar. Here is my prepare() method:
>
> public void prepare() throws Exception {
> if( this.id==0 ) {
> this.entity = new Entity();
> } else {
> this.entity = this.entityDao.findById(this.id);
> }
> }
>
> Here is the (obvious) getModel():
>
> public Object getModel() {
> return this.entity;
> }
>
> Here is the update, "execute()" method that is called upon form
> submission:
>
> @Validations(
> requiredStrings =
> {@RequiredStringValidator(fieldName = "model.name",
> message = "You must enter a title.")}
> )
> public String update() {
> if( this.id==0 ) {
> this.entityDao.create(this.entity);
> } else {
> this.entity.update(this.entity);
> }
> return SUCCESS;
> }
>
> So when a user enters a blank "model.name" field, this.entity.name
> property gets set to null, the update() method never is called, but
> Hibernate tries to write the update to the database when
> OpenEntityManagerInViewFilter closes the EntityManager:
>
> Here is the relevant code from OpenEntityManagerInViewFilter
>
> protected void doFilterInternal(
> HttpServletRequest request, HttpServletResponse
> response, FilterChain filterChain)
> throws ServletException, IOException {
>
> ...
>
> try {
> filterChain.doFilter(request, response);
> }
>
> finally {
> if (!participate) {
> EntityManagerHolder emHolder =
> (EntityManagerHolder)
> TransactionSynchronizationManager.unbindResource(emf);
> emHolder.getEntityManager().close();
> }
> }
> }
>
> 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
>
>
>
> "Musachy Barroso" <mu...@gmail.com>
> 10/01/2007 05:10 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
>
>
>
>
>
>
> I only use the beanutils.copy solution on a few places, on the other
> cases I always load the object model on the prepare() method if the
> "id" field is set (editing), and then call update or create on the
> entity manager in my action method. I never got that problem so I'm
> wondering what is different. (I use JPA on top of hibernate)
>
> musachy
>
> On 10/1/07, Dave Newton <ne...@yahoo.com> wrote:
> > --- 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
> >
> >
>
>
> --
> "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
>
>
>
--
"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
Posted by Jo...@fws.gov.
Yes, musachy. I do something very similar. Here is my prepare() method:
public void prepare() throws Exception {
if( this.id==0 ) {
this.entity = new Entity();
} else {
this.entity = this.entityDao.findById(this.id);
}
}
Here is the (obvious) getModel():
public Object getModel() {
return this.entity;
}
Here is the update, "execute()" method that is called upon form
submission:
@Validations(
requiredStrings =
{@RequiredStringValidator(fieldName = "model.name",
message = "You must enter a title.")}
)
public String update() {
if( this.id==0 ) {
this.entityDao.create(this.entity);
} else {
this.entity.update(this.entity);
}
return SUCCESS;
}
So when a user enters a blank "model.name" field, this.entity.name
property gets set to null, the update() method never is called, but
Hibernate tries to write the update to the database when
OpenEntityManagerInViewFilter closes the EntityManager:
Here is the relevant code from OpenEntityManagerInViewFilter
protected void doFilterInternal(
HttpServletRequest request, HttpServletResponse
response, FilterChain filterChain)
throws ServletException, IOException {
...
try {
filterChain.doFilter(request, response);
}
finally {
if (!participate) {
EntityManagerHolder emHolder =
(EntityManagerHolder)
TransactionSynchronizationManager.unbindResource(emf);
emHolder.getEntityManager().close();
}
}
}
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
"Musachy Barroso" <mu...@gmail.com>
10/01/2007 05:10 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
I only use the beanutils.copy solution on a few places, on the other
cases I always load the object model on the prepare() method if the
"id" field is set (editing), and then call update or create on the
entity manager in my action method. I never got that problem so I'm
wondering what is different. (I use JPA on top of hibernate)
musachy
On 10/1/07, Dave Newton <ne...@yahoo.com> wrote:
> --- 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
>
>
--
"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
Posted by Musachy Barroso <mu...@gmail.com>.
I only use the beanutils.copy solution on a few places, on the other
cases I always load the object model on the prepare() method if the
"id" field is set (editing), and then call update or create on the
entity manager in my action method. I never got that problem so I'm
wondering what is different. (I use JPA on top of hibernate)
musachy
On 10/1/07, Dave Newton <ne...@yahoo.com> wrote:
> --- 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
>
>
--
"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 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
Re: ModelDriven CRUD validation failure still causes JPA update - RESOLVED
Posted by Jo...@fws.gov.
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: ModelDriven CRUD validation failure still causes JPA update
Posted by Jo...@fws.gov.
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: ModelDriven CRUD validation failure still causes JPA update
Posted by Dave Newton <ne...@yahoo.com>.
--- 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: ModelDriven CRUD validation failure still causes JPA update
Posted by Jo...@fws.gov.
That's an interesting idea Dave. I'm using the paramsPrepareStack. It'll
take some investigation to see if that would fix the issue.
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
Dave Newton <ne...@yahoo.com>
10/01/2007 03:32 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
I haven't tried this, but perhaps changing the order
the interceptors are specified is a potential way out.
--- Jon_French@fws.gov wrote:
> True. The action's "execute" method is not being
> called. However, in the
> ModelDriven pattern, the invalid (in my case Null)
> request parameters are
> set on the Model during request processing. This is
> opposed to a
> non-ModelDriven action where the parameters would be
> set on Action
> properties.
>
> Since my Model is acquired from the Hibernate
> session (during the
> "prepare()" Action method), it is a transactional
> persistent instance.
> Note this from the hibernate documentation:
>
> "Transactional persistent instances (ie. objects
> loaded, saved, created or
> queried by the Session) may be manipulated by the
> application and any
> changes to persistent state will be persisted when
> the Session is flushed
> (discussed later in this chapter). There is no need
> to call a particular
> method (like update(), which has a different
> purpose) to make your
> modifications persistent."
>
(
http://www.hibernate.org/hib_docs/v3/reference/en/html/objectstate.html#objectstate-modifying
)
>
> So when the OpenEntityManagerInView filter closes
> the EntityManager at the
> end of request processing (even when validation
> fails), Hibernate attempts
> to write the invalid model object to the database.
>
> 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
>
>
>
> "Musachy Barroso" <mu...@gmail.com>
> 10/01/2007 02: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
>
>
>
>
>
>
> If there is a validation error the code on your
> action shouldn't be
> executed at all, so you wouldn't have this problem.
> Are you applying
> the "defaultWorkflow" interceptor to your action?
>
> regards
> musachy
>
> On 10/1/07, Jon_French@fws.gov <Jo...@fws.gov>
> wrote:
> > I have a ModelDriven action which controls CRUD
> operations on JPA
> managed
> > Entity E. E has a property called ?name? which
> maps to a database column
> > with a NOT NULL constraint. I have added a
> RequiredStringValidator
> > annotation to my Action to validate that the
> ?model.name? property is
> > non-null. The validation works perfectly.
> > However, during Struts Interceptor processing of a
> user entered empty
> > string for the ?model.name? ServletRequest
> parameter, entity instance E
> > has its getName() property set to a null value.
> Hibernate (my JPA
> > implementation provider) detects this property
> state change when the
> > Hibernate session is flushed at the closing of the
> JPA EntityManager by
> > the configured OpenEntityManagerInView
> ServletFilter. This results in an
> > attempt by Hibernate to update the ?name? database
> column to null and
> > results in a SqlException.
> > So the problem is that even with appropriate
> validation on a ModelDriven
> > action, my Entity moves to an invalid state which
> Hibernate then tries
> to
> > persist to the database at the closing of the
> session.
> > Based on what I gleaned from this WebWorkx post:
> >
>
http://forums.opensymphony.com/thread.jspa?messageID=5315ᓃ
> > (which seems to be the exact same problem except
> with the
> > OpenSessionInView filter instead of my
> OpenEntityManagerInView filter)
> > And this spring post:
> >
>
http://forum.springframework.org/showthread.php?t=35740
> > ? I think that what I need to do is set
> Hibernate?s flush mode to
> NEVER.
> > What this means to me is that Hibernate will only
> flush when I execute a
> > EntityManager.flush() command and that
> OpenEntityManagerInView?s closing
> > of the EntityManager won?t automatically result in
> a Hibernate session
> > flush and thus Entity E?s invalid state will not
> be persisted. This is
> in
> > line with what I understand to be the default
> behavior of Spring?s
> > OpenSessionInView filter. Unfortunately, I have
> not yet been able to set
> > Hibernate's flush mode (nor am I certain that this
> will solve my issue).
> > Can anyone shed some light on this problem?
> > Thanks in advance!
> >
> > 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
>
>
> --
> "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
>
>
>
---------------------------------------------------------------------
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
Posted by Dave Newton <ne...@yahoo.com>.
I haven't tried this, but perhaps changing the order
the interceptors are specified is a potential way out.
--- Jon_French@fws.gov wrote:
> True. The action's "execute" method is not being
> called. However, in the
> ModelDriven pattern, the invalid (in my case Null)
> request parameters are
> set on the Model during request processing. This is
> opposed to a
> non-ModelDriven action where the parameters would be
> set on Action
> properties.
>
> Since my Model is acquired from the Hibernate
> session (during the
> "prepare()" Action method), it is a transactional
> persistent instance.
> Note this from the hibernate documentation:
>
> "Transactional persistent instances (ie. objects
> loaded, saved, created or
> queried by the Session) may be manipulated by the
> application and any
> changes to persistent state will be persisted when
> the Session is flushed
> (discussed later in this chapter). There is no need
> to call a particular
> method (like update(), which has a different
> purpose) to make your
> modifications persistent."
>
(http://www.hibernate.org/hib_docs/v3/reference/en/html/objectstate.html#objectstate-modifying)
>
> So when the OpenEntityManagerInView filter closes
> the EntityManager at the
> end of request processing (even when validation
> fails), Hibernate attempts
> to write the invalid model object to the database.
>
> 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
>
>
>
> "Musachy Barroso" <mu...@gmail.com>
> 10/01/2007 02: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
>
>
>
>
>
>
> If there is a validation error the code on your
> action shouldn't be
> executed at all, so you wouldn't have this problem.
> Are you applying
> the "defaultWorkflow" interceptor to your action?
>
> regards
> musachy
>
> On 10/1/07, Jon_French@fws.gov <Jo...@fws.gov>
> wrote:
> > I have a ModelDriven action which controls CRUD
> operations on JPA
> managed
> > Entity E. E has a property called ?name? which
> maps to a database column
> > with a NOT NULL constraint. I have added a
> RequiredStringValidator
> > annotation to my Action to validate that the
> ?model.name? property is
> > non-null. The validation works perfectly.
> > However, during Struts Interceptor processing of a
> user entered empty
> > string for the ?model.name? ServletRequest
> parameter, entity instance E
> > has its getName() property set to a null value.
> Hibernate (my JPA
> > implementation provider) detects this property
> state change when the
> > Hibernate session is flushed at the closing of the
> JPA EntityManager by
> > the configured OpenEntityManagerInView
> ServletFilter. This results in an
> > attempt by Hibernate to update the ?name? database
> column to null and
> > results in a SqlException.
> > So the problem is that even with appropriate
> validation on a ModelDriven
> > action, my Entity moves to an invalid state which
> Hibernate then tries
> to
> > persist to the database at the closing of the
> session.
> > Based on what I gleaned from this WebWorkx post:
> >
>
http://forums.opensymphony.com/thread.jspa?messageID=5315ᓃ
> > (which seems to be the exact same problem except
> with the
> > OpenSessionInView filter instead of my
> OpenEntityManagerInView filter)
> > And this spring post:
> >
>
http://forum.springframework.org/showthread.php?t=35740
> > ? I think that what I need to do is set
> Hibernate?s flush mode to
> NEVER.
> > What this means to me is that Hibernate will only
> flush when I execute a
> > EntityManager.flush() command and that
> OpenEntityManagerInView?s closing
> > of the EntityManager won?t automatically result in
> a Hibernate session
> > flush and thus Entity E?s invalid state will not
> be persisted. This is
> in
> > line with what I understand to be the default
> behavior of Spring?s
> > OpenSessionInView filter. Unfortunately, I have
> not yet been able to set
> > Hibernate's flush mode (nor am I certain that this
> will solve my issue).
> > Can anyone shed some light on this problem?
> > Thanks in advance!
> >
> > 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
>
>
> --
> "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
>
>
>
---------------------------------------------------------------------
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
Posted by Jo...@fws.gov.
True. The action's "execute" method is not being called. However, in the
ModelDriven pattern, the invalid (in my case Null) request parameters are
set on the Model during request processing. This is opposed to a
non-ModelDriven action where the parameters would be set on Action
properties.
Since my Model is acquired from the Hibernate session (during the
"prepare()" Action method), it is a transactional persistent instance.
Note this from the hibernate documentation:
"Transactional persistent instances (ie. objects loaded, saved, created or
queried by the Session) may be manipulated by the application and any
changes to persistent state will be persisted when the Session is flushed
(discussed later in this chapter). There is no need to call a particular
method (like update(), which has a different purpose) to make your
modifications persistent."
(http://www.hibernate.org/hib_docs/v3/reference/en/html/objectstate.html#objectstate-modifying)
So when the OpenEntityManagerInView filter closes the EntityManager at the
end of request processing (even when validation fails), Hibernate attempts
to write the invalid model object to the database.
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
"Musachy Barroso" <mu...@gmail.com>
10/01/2007 02: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
If there is a validation error the code on your action shouldn't be
executed at all, so you wouldn't have this problem. Are you applying
the "defaultWorkflow" interceptor to your action?
regards
musachy
On 10/1/07, Jon_French@fws.gov <Jo...@fws.gov> wrote:
> I have a ModelDriven action which controls CRUD operations on JPA
managed
> Entity E. E has a property called ?name? which maps to a database column
> with a NOT NULL constraint. I have added a RequiredStringValidator
> annotation to my Action to validate that the ?model.name? property is
> non-null. The validation works perfectly.
> However, during Struts Interceptor processing of a user entered empty
> string for the ?model.name? ServletRequest parameter, entity instance E
> has its getName() property set to a null value. Hibernate (my JPA
> implementation provider) detects this property state change when the
> Hibernate session is flushed at the closing of the JPA EntityManager by
> the configured OpenEntityManagerInView ServletFilter. This results in an
> attempt by Hibernate to update the ?name? database column to null and
> results in a SqlException.
> So the problem is that even with appropriate validation on a ModelDriven
> action, my Entity moves to an invalid state which Hibernate then tries
to
> persist to the database at the closing of the session.
> Based on what I gleaned from this WebWorkx post:
> http://forums.opensymphony.com/thread.jspa?messageID=5315ᓃ
> (which seems to be the exact same problem except with the
> OpenSessionInView filter instead of my OpenEntityManagerInView filter)
> And this spring post:
> http://forum.springframework.org/showthread.php?t=35740
> ? I think that what I need to do is set Hibernate?s flush mode to
NEVER.
> What this means to me is that Hibernate will only flush when I execute a
> EntityManager.flush() command and that OpenEntityManagerInView?s closing
> of the EntityManager won?t automatically result in a Hibernate session
> flush and thus Entity E?s invalid state will not be persisted. This is
in
> line with what I understand to be the default behavior of Spring?s
> OpenSessionInView filter. Unfortunately, I have not yet been able to set
> Hibernate's flush mode (nor am I certain that this will solve my issue).
> Can anyone shed some light on this problem?
> Thanks in advance!
>
> 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
--
"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
Posted by Musachy Barroso <mu...@gmail.com>.
If there is a validation error the code on your action shouldn't be
executed at all, so you wouldn't have this problem. Are you applying
the "defaultWorkflow" interceptor to your action?
regards
musachy
On 10/1/07, Jon_French@fws.gov <Jo...@fws.gov> wrote:
> I have a ModelDriven action which controls CRUD operations on JPA managed
> Entity E. E has a property called ?name? which maps to a database column
> with a NOT NULL constraint. I have added a RequiredStringValidator
> annotation to my Action to validate that the ?model.name? property is
> non-null. The validation works perfectly.
> However, during Struts Interceptor processing of a user entered empty
> string for the ?model.name? ServletRequest parameter, entity instance E
> has its getName() property set to a null value. Hibernate (my JPA
> implementation provider) detects this property state change when the
> Hibernate session is flushed at the closing of the JPA EntityManager by
> the configured OpenEntityManagerInView ServletFilter. This results in an
> attempt by Hibernate to update the ?name? database column to null and
> results in a SqlException.
> So the problem is that even with appropriate validation on a ModelDriven
> action, my Entity moves to an invalid state which Hibernate then tries to
> persist to the database at the closing of the session.
> Based on what I gleaned from this WebWorkx post:
> http://forums.opensymphony.com/thread.jspa?messageID=5315ᓃ
> (which seems to be the exact same problem except with the
> OpenSessionInView filter instead of my OpenEntityManagerInView filter)
> And this spring post:
> http://forum.springframework.org/showthread.php?t=35740
> ? I think that what I need to do is set Hibernate?s flush mode to NEVER.
> What this means to me is that Hibernate will only flush when I execute a
> EntityManager.flush() command and that OpenEntityManagerInView?s closing
> of the EntityManager won?t automatically result in a Hibernate session
> flush and thus Entity E?s invalid state will not be persisted. This is in
> line with what I understand to be the default behavior of Spring?s
> OpenSessionInView filter. Unfortunately, I have not yet been able to set
> Hibernate's flush mode (nor am I certain that this will solve my issue).
> Can anyone shed some light on this problem?
> Thanks in advance!
>
> 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
--
"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