Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
In-Reply-To: <002c01c804bb$81b976b0$5fdba8c0@AlLaptop>
To: "Struts Users Mailing List" <user@struts.apache.org>
Subject: RE: ModelDriven CRUD validation failure still causes JPA update -
 RESOLVED
MIME-Version: 1.0
Message-ID: 
 <OF2B9E42C5.86D4EB9C-ON87257368.00542B49-87257368.0054B5FE@fws.gov>
From: Jon_French@fws.gov
Date: Tue, 2 Oct 2007 09:26:08 -0600
Content-Type: multipart/alternative;
 boundary="=_alternative 0054B5FB87257368_="

--=_alternative 0054B5FB87257368_=
Content-Type: text/plain; charset="US-ASCII"

Yes. But I am using Spring managed transactions that in my understanding 
are outside of the struts Interceptor stack. 

My DAO's are annotated with the 
org.springframework.transaction.annotation.Transactional annotation and 
thus have their transactions managed as detailed here:

http://static.springframework.org/spring/docs/2.0.x/reference/transaction.html

I'm not an expert (I've only devoted a bit of time to studying the above 
link), but it is my understanding that Spring wraps my DAO methods with 
Aspects which control Transaction management (opening/closing).

best,
 
Jon French
Programmer
ASRC Management Services
ECOS Development Team
jon_french@fws.gov
970-226-9290

Fort Collins Science Center
US Geological Survey
2150 Centre Ave, Building C
Fort Collins, CO 80526-8116


"Al Sutton" <al.sutton@alsutton.com> 
10/02/2007 12:14 AM
Please respond to
"Struts Users Mailing List" <user@struts.apache.org>


To
"'Struts Users Mailing List'" <user@struts.apache.org>
cc

Subject
RE: ModelDriven CRUD validation failure still causes JPA update - RESOLVED


Just a thought, are you actually using transactions?

If so why not modify the interceptor to only commit if a SUCCESS is 
returned
or perform a rollback if ERROR is returned from the action invocation.

Al.

-----Original Message-----
From: Jon_French@fws.gov [mailto:Jon_French@fws.gov] 
Sent: 02 October 2007 04:04
To: Struts Users Mailing List
Subject: Re: ModelDriven CRUD validation failure still causes JPA update -
RESOLVED


OK: I've fixed the problem.

I'm not sure why this was the case, but here is what was causing the 
problem:

In my ModelDriven action, I had a method like this:

    public Collection<ProjectType> getAllProjectTypes(){
        return this.projectTypeDao.getAll();
    }

Notice that instead of returning a simple instance reference, this method 
actually returned the result of a JPA query (via the DAO method call).

This method was used by a struts 2 iterator tag to populate a select list 
on the form and was thus called when my "input" JSP rendered after an 
invalid request. 

I noticed that in the stack trace of my Oracle constraint violation, it 
was actually this query call that was triggering the Session.flush() call 
that was inappropriately saving the invalid entity state to the database. 
By "pre-loading" the collection in the prepare() method like so:

    public void prepare() throws Exception {
       ....
       this.allProjectTypes = this.projectTypeDao.getAll();
    }

    public Collection<ProjectType> getAllProjectTypes(){
        return this.allProjectTypes;
    }

... the problematic flush() goes away.

Beats me why this matters. I'm sure a JPA guru could explain something 
about the Transaction or EntityManager instance being different in the two 

cases, but I don't understand it yet.

Jon French
Programmer
ASRC Management Services
ECOS Development Team
jon_french@fws.gov
970-226-9290

Fort Collins Science Center
US Geological Survey
2150 Centre Ave, Building C
Fort Collins, CO 80526-8116


Jon_French@fws.gov 
10/01/2007 08:29 PM
Please respond to
"Struts Users Mailing List" <user@struts.apache.org>


To
"Struts Users Mailing List" <user@struts.apache.org>
cc

Subject
Re: ModelDriven CRUD validation failure still causes JPA update


Unfortunately, it appears that xworks validation works not on the 
ServletRequest parameters, but on the properties already set on the Action 


- or in my case the model bean. So moving the interceptor up the stack 
would just break validation. 

>From the com.opensymphony.xwork2.validator.ValidationInterceptor javadoc:

 * This interceptor runs the action through the standard validation 
framework, which in turn checks the action against
 * any validation rules (found in files such as 
<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 <newton.dave@yahoo.com> 
10/01/2007 04:42 PM
Please respond to
"Struts Users Mailing List" <user@struts.apache.org>


To
Struts Users Mailing List <user@struts.apache.org>
cc

Subject
Re: ModelDriven CRUD validation failure still causes JPA update


--- Jon_French@fws.gov wrote:
> That's an interesting idea Dave. I'm using the paramsPrepareStack. 
> It'll take some investigation to

> see if that would fix the issue.

Shouldn't take much; it might be as simple as adding a
validate/defaultWorkFlow up towards the top (although I might try just
adding new ones rather than removing the existing ones).

> Fort Collins Science Center
> US Geological Survey
> 2150 Centre Ave, Building C

I used to live up Poudre River Canyon (Poudre Park); I
sure miss the climbing out there :(

d.


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


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


--=_alternative 0054B5FB87257368_=--