Re: RE: Re : Re : ModelDriven & Hibernate Entities
I think your fix sounds logical. My true knowledge of the @Transactional annotation isn't that great although I use it quite a bit (yikes), so this suggestion may be way off base but would setting the code inside your pre-result or post-result inteceptor as @Transactional(propagation = Propagation.REQUIRES_NEW) help in any way? On Fri, Mar 11, 2011 at 9:10 AM, CRANFORD, CHRIS wrote: > Burton - > > I continued to dig around the code yesterday despite my frustration with the > situation in not being able to find a way to make all this work. It just > didn't seem right that this wouldn't work IMO. After turning on Spring's > DEBUG and watching the transaction management statements happen, I stumbled > across what I feel was the culprit. > > We have a number of interceptors in our code base that perform various > initialization activities before the destination action is ever invoked along > with some which do pre-result and post-result activities. After looking at > my interceptor stack, one of them was doing a merge action to write some > breadcrumb data to an audit table during a pre-result listener. > > So the series of events were: > > 1. Model Driven action called > 2. Model loaded from database (attached entity) > 3. Parameters were loaded into model (entity now modified) > 4. Validation occurred > 5. Execute method fired (simply returns SUCCESS) > > Well after the action returns SUCCESS and the PreResultListener gets executed > that does the EntityManager MERGE call. This not only persisted the audit > record to the database but it also commits any changes pending, which would > include the modified entity in #3 above. > > From what I have gathered with OSIV, the transaction is opened and you can > query the database and make changes to your entities but once a call is made > to the entity manager to remove/persist/merge an entity, all bets are off; > any pending changes will be flushed. > > So what I decided to test was adding one more interceptor to the stack that > clears the entity manager after the action's execution; effectively forcing a > rollback for any entities which were not explicitly persisted. Then the > audit interceptor was changed from a pre-result to a post-result action and > takes place right after the clearing of my entity manager. Now the audit > service doesn't persist any pending changes from my action environment. > > Anyone see any flaws or issues with this? So long as my action is making a > single call in my execute() method to my business logic with my model, then I > should be ok? > >> -Original Message- >> From: Burton Rhodes [mailto:burtonrho...@gmail.com] >> Sent: Thursday, March 10, 2011 7:49 PM >> To: Struts Users Mailing List >> Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities >> >> I have never run into this issue while using OiSV, but couldn't it be >> easily solved by not referencing any related entity or collections >> directly from the model you are modifying in your action? In other >> words, the object that is in your model (e.g Customer) would be in >> getModel() and in the form for the JSP, but all other data dispayed on >> the page would be reference by a "clean" version of Customer. I'm >> sure it can't be that simple, but trying to help. >> >> On Thu, Mar 10, 2011 at 7:39 PM, Burton Rhodes >> wrote: >> > Here is an old thread talking of this same issue. It appears some >> > suggestions are given, but still an issue. Dave was *marginally* >> > following this thread as well ;-) >> > >> > http://www.coderanch.com/t/58423/Struts/Struts-Model-Driven- >> fundamentally-flawed >> > >> > >> > On Thu, Mar 10, 2011 at 11:55 AM, CRANFORD, CHRIS >> > wrote: >> >> Dave et el - >> >> >> >> I can only conclude that either something is severely lost in my >> >> understanding of a Struts2 ModelDriven action coupled with Spring3 >> and >> >> Hibernate/JPA. I have tried numerous configuration changes, >> >> annotations, etc and nothing has appeared to avoid allowing dirty >> data >> >> to make it to the database and I just cannot continue with this >> risk; it >> >> just jeopardizes integrity. >> >> >> >> So unless someone can shed some light on my implementation, showing >> what >> >> could be flawed; then I need to go down a different path. >> >> >> >> I like the notion that the ModelDriven does a lot of the grunt work >> for >> >> me with respect of p
RE: RE: Re : Re : ModelDriven & Hibernate Entities
Burton - I continued to dig around the code yesterday despite my frustration with the situation in not being able to find a way to make all this work. It just didn't seem right that this wouldn't work IMO. After turning on Spring's DEBUG and watching the transaction management statements happen, I stumbled across what I feel was the culprit. We have a number of interceptors in our code base that perform various initialization activities before the destination action is ever invoked along with some which do pre-result and post-result activities. After looking at my interceptor stack, one of them was doing a merge action to write some breadcrumb data to an audit table during a pre-result listener. So the series of events were: 1. Model Driven action called 2. Model loaded from database (attached entity) 3. Parameters were loaded into model (entity now modified) 4. Validation occurred 5. Execute method fired (simply returns SUCCESS) Well after the action returns SUCCESS and the PreResultListener gets executed that does the EntityManager MERGE call. This not only persisted the audit record to the database but it also commits any changes pending, which would include the modified entity in #3 above. >From what I have gathered with OSIV, the transaction is opened and you can >query the database and make changes to your entities but once a call is made >to the entity manager to remove/persist/merge an entity, all bets are off; any >pending changes will be flushed. So what I decided to test was adding one more interceptor to the stack that clears the entity manager after the action's execution; effectively forcing a rollback for any entities which were not explicitly persisted. Then the audit interceptor was changed from a pre-result to a post-result action and takes place right after the clearing of my entity manager. Now the audit service doesn't persist any pending changes from my action environment. Anyone see any flaws or issues with this? So long as my action is making a single call in my execute() method to my business logic with my model, then I should be ok? > -Original Message- > From: Burton Rhodes [mailto:burtonrho...@gmail.com] > Sent: Thursday, March 10, 2011 7:49 PM > To: Struts Users Mailing List > Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities > > I have never run into this issue while using OiSV, but couldn't it be > easily solved by not referencing any related entity or collections > directly from the model you are modifying in your action? In other > words, the object that is in your model (e.g Customer) would be in > getModel() and in the form for the JSP, but all other data dispayed on > the page would be reference by a "clean" version of Customer. I'm > sure it can't be that simple, but trying to help. > > On Thu, Mar 10, 2011 at 7:39 PM, Burton Rhodes > wrote: > > Here is an old thread talking of this same issue. It appears some > > suggestions are given, but still an issue. Dave was *marginally* > > following this thread as well ;-) > > > > http://www.coderanch.com/t/58423/Struts/Struts-Model-Driven- > fundamentally-flawed > > > > > > On Thu, Mar 10, 2011 at 11:55 AM, CRANFORD, CHRIS > > wrote: > >> Dave et el - > >> > >> I can only conclude that either something is severely lost in my > >> understanding of a Struts2 ModelDriven action coupled with Spring3 > and > >> Hibernate/JPA. I have tried numerous configuration changes, > >> annotations, etc and nothing has appeared to avoid allowing dirty > data > >> to make it to the database and I just cannot continue with this > risk; it > >> just jeopardizes integrity. > >> > >> So unless someone can shed some light on my implementation, showing > what > >> could be flawed; then I need to go down a different path. > >> > >> I like the notion that the ModelDriven does a lot of the grunt work > for > >> me with respect of populating my entity based on form properties and > >> keeps my action class very clean and free of form bloat; however I > feel > >> it puts some risks on the table which I could easily avoid by not > >> allowing the framework to modify my persistent entity and force me > to > >> manage the copy/update of the entity accordingly when applicable. > >> > >>> -Original Message- > >>> From: Dave Newton [mailto:davelnew...@gmail.com] > >>> Sent: Thursday, March 10, 2011 10:40 AM > >>> To: CRANFORD, CHRIS > >>> Cc: Struts Users Mailing List; Maurizio Cucchiara > >>> Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities >
RE: Re : Re : ModelDriven & Hibernate Entities
mp;
(newStack.getContext() != null))
stack.getContext().put(ActionContext.CONVERSION_ERRORS,
newStack.getContext().get(ActionContext.CONVERSION_ERRORS));
addParametersToContext(ActionContext.getContext(),
acceptableParameters);
}
protected void addParametersToContext(ActionContext ac, Map
newParams)
{
}
Martin Gainty
__
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und
Vertraulichkeitanmerkung/Note de déni et de confidentialité
Ez az
üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és
semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek
könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
ezen üzenet tartalma miatt.
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
> Date: Thu, 10 Mar 2011 19:39:56 -0600
> Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities
> From: burtonrho...@gmail.com
> To: user@struts.apache.org
>
> Here is an old thread talking of this same issue. It appears some
> suggestions are given, but still an issue. Dave was *marginally*
> following this thread as well ;-)
>
> http://www.coderanch.com/t/58423/Struts/Struts-Model-Driven-fundamentally-flawed
>
>
> On Thu, Mar 10, 2011 at 11:55 AM, CRANFORD, CHRIS
> wrote:
> > Dave et el -
> >
> > I can only conclude that either something is severely lost in my
> > understanding of a Struts2 ModelDriven action coupled with Spring3 and
> > Hibernate/JPA. I have tried numerous configuration changes,
> > annotations, etc and nothing has appeared to avoid allowing dirty data
> > to make it to the database and I just cannot continue with this risk; it
> > just jeopardizes integrity.
> >
> > So unless someone can shed some light on my implementation, showing what
> > could be flawed; then I need to go down a different path.
> >
> > I like the notion that the ModelDriven does a lot of the grunt work for
> > me with respect of populating my entity based on form properties and
> > keeps my action class very clean and free of form bloat; however I feel
> > it puts some risks on the table which I could easily avoid by not
> > allowing the framework to modify my persistent entity and force me to
> > manage the copy/update of the entity accordingly when applicable.
> >
> >> -Original Message-
> >> From: Dave Newton [mailto:davelnew...@gmail.com]
> >> Sent: Thursday, March 10, 2011 10:40 AM
> >> To: CRANFORD, CHRIS
> >> Cc: Struts Users Mailing List; Maurizio Cucchiara
> >> Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities
> >>
> >> On Thu, Mar 10, 2011 at 11:38 AM, CRANFORD, CHRIS wrote:
> >> > Yes the plugin is in the app's lib directory.
> >>
> >> Just FYI, that sets the object factory to "spring", so Spring is
> >> instantiating your actions.
> >>
> >> (At least it used to.)
> >>
> >> Dave
> >
> >
> >
> > -
> > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> > For additional commands, e-mail: user-h...@struts.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> For additional commands, e-mail: user-h...@struts.apache.org
>
Re: RE: Re : Re : ModelDriven & Hibernate Entities
I have never run into this issue while using OiSV, but couldn't it be easily solved by not referencing any related entity or collections directly from the model you are modifying in your action? In other words, the object that is in your model (e.g Customer) would be in getModel() and in the form for the JSP, but all other data dispayed on the page would be reference by a "clean" version of Customer. I'm sure it can't be that simple, but trying to help. On Thu, Mar 10, 2011 at 7:39 PM, Burton Rhodes wrote: > Here is an old thread talking of this same issue. It appears some > suggestions are given, but still an issue. Dave was *marginally* > following this thread as well ;-) > > http://www.coderanch.com/t/58423/Struts/Struts-Model-Driven-fundamentally-flawed > > > On Thu, Mar 10, 2011 at 11:55 AM, CRANFORD, CHRIS > wrote: >> Dave et el - >> >> I can only conclude that either something is severely lost in my >> understanding of a Struts2 ModelDriven action coupled with Spring3 and >> Hibernate/JPA. I have tried numerous configuration changes, >> annotations, etc and nothing has appeared to avoid allowing dirty data >> to make it to the database and I just cannot continue with this risk; it >> just jeopardizes integrity. >> >> So unless someone can shed some light on my implementation, showing what >> could be flawed; then I need to go down a different path. >> >> I like the notion that the ModelDriven does a lot of the grunt work for >> me with respect of populating my entity based on form properties and >> keeps my action class very clean and free of form bloat; however I feel >> it puts some risks on the table which I could easily avoid by not >> allowing the framework to modify my persistent entity and force me to >> manage the copy/update of the entity accordingly when applicable. >> >>> -Original Message- >>> From: Dave Newton [mailto:davelnew...@gmail.com] >>> Sent: Thursday, March 10, 2011 10:40 AM >>> To: CRANFORD, CHRIS >>> Cc: Struts Users Mailing List; Maurizio Cucchiara >>> Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities >>> >>> On Thu, Mar 10, 2011 at 11:38 AM, CRANFORD, CHRIS wrote: >>> > Yes the plugin is in the app's lib directory. >>> >>> Just FYI, that sets the object factory to "spring", so Spring is >>> instantiating your actions. >>> >>> (At least it used to.) >>> >>> Dave >> >> >> >> - >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> For additional commands, e-mail: user-h...@struts.apache.org >> >> > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: RE: Re : Re : ModelDriven & Hibernate Entities
Here is an old thread talking of this same issue. It appears some suggestions are given, but still an issue. Dave was *marginally* following this thread as well ;-) http://www.coderanch.com/t/58423/Struts/Struts-Model-Driven-fundamentally-flawed On Thu, Mar 10, 2011 at 11:55 AM, CRANFORD, CHRIS wrote: > Dave et el - > > I can only conclude that either something is severely lost in my > understanding of a Struts2 ModelDriven action coupled with Spring3 and > Hibernate/JPA. I have tried numerous configuration changes, > annotations, etc and nothing has appeared to avoid allowing dirty data > to make it to the database and I just cannot continue with this risk; it > just jeopardizes integrity. > > So unless someone can shed some light on my implementation, showing what > could be flawed; then I need to go down a different path. > > I like the notion that the ModelDriven does a lot of the grunt work for > me with respect of populating my entity based on form properties and > keeps my action class very clean and free of form bloat; however I feel > it puts some risks on the table which I could easily avoid by not > allowing the framework to modify my persistent entity and force me to > manage the copy/update of the entity accordingly when applicable. > >> -Original Message- >> From: Dave Newton [mailto:davelnew...@gmail.com] >> Sent: Thursday, March 10, 2011 10:40 AM >> To: CRANFORD, CHRIS >> Cc: Struts Users Mailing List; Maurizio Cucchiara >> Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities >> >> On Thu, Mar 10, 2011 at 11:38 AM, CRANFORD, CHRIS wrote: >> > Yes the plugin is in the app's lib directory. >> >> Just FYI, that sets the object factory to "spring", so Spring is >> instantiating your actions. >> >> (At least it used to.) >> >> Dave > > > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
RE: RE: Re : Re : ModelDriven & Hibernate Entities
Dave et el - I can only conclude that either something is severely lost in my understanding of a Struts2 ModelDriven action coupled with Spring3 and Hibernate/JPA. I have tried numerous configuration changes, annotations, etc and nothing has appeared to avoid allowing dirty data to make it to the database and I just cannot continue with this risk; it just jeopardizes integrity. So unless someone can shed some light on my implementation, showing what could be flawed; then I need to go down a different path. I like the notion that the ModelDriven does a lot of the grunt work for me with respect of populating my entity based on form properties and keeps my action class very clean and free of form bloat; however I feel it puts some risks on the table which I could easily avoid by not allowing the framework to modify my persistent entity and force me to manage the copy/update of the entity accordingly when applicable. > -Original Message- > From: Dave Newton [mailto:davelnew...@gmail.com] > Sent: Thursday, March 10, 2011 10:40 AM > To: CRANFORD, CHRIS > Cc: Struts Users Mailing List; Maurizio Cucchiara > Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities > > On Thu, Mar 10, 2011 at 11:38 AM, CRANFORD, CHRIS wrote: > > Yes the plugin is in the app's lib directory. > > Just FYI, that sets the object factory to "spring", so Spring is > instantiating your actions. > > (At least it used to.) > > Dave - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
RE: RE: Re : Re : ModelDriven & Hibernate Entities
Annotating @Transactional on the action didn't help. > -Original Message- > From: Maurizio Cucchiara [mailto:maurizio.cucchi...@gmail.com] > Sent: Thursday, March 10, 2011 1:41 AM > To: Struts Users Mailing List > Cc: CRANFORD, CHRIS > Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities > > It's exactly what I meant (you can leave in your service class too). > The object factory must be spring and your class name inside the > action configuration must contain the bean id (instead of the real > class name). > I'm not sure if it works but it worth a try though. > > On 10 March 2011 00:08, CRANFORD, CHRIS > wrote: > > In the Struts2 Action rather than my service class? > > > >> -Original Message- > >> From: Maurizio Cucchiara [mailto:maurizio.cucchi...@gmail.com] > >> Sent: Wednesday, March 09, 2011 4:20 PM > >> To: Struts Users Mailing List > >> Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities > >> > >> Have you tried to put the transational annotation in the class > >> declaration? > >> > >> Maurizio Cucchiara > >> > >> Il giorno 09/mar/2011 21.38, "CRANFORD, CHRIS" > >> > >> ha scritto: > >> > I still think this is related to my @Transactional annotation > maybe. > >> > > >> >> -Original Message- > >> >> From: Dave Newton [mailto:davelnew...@gmail.com] > >> >> Sent: Wednesday, March 09, 2011 2:16 PM > >> >> To: Struts Users Mailing List > >> >> Subject: Re: Re : Re : ModelDriven & Hibernate Entities > >> >> > >> >> Another reason OSiV filters can be tricky. > >> >> > >> >> Dave > >> >> > >> >> On Wed, Mar 9, 2011 at 2:04 PM, CRANFORD, CHRIS > >> >> wrote: > >> >> > Francois - > >> >> > > >> >> > I use the standard paramsPrepareParamsStack interceptor from > >> Struts. > >> >> > > >> >> > All I have done on my end is wrap this interceptor stack with a > >> few > >> >> application specific interceptors that control things such as > >> >> authentication required, auditing, and logging. I stepped upon > my > >> >> issue one day when I had returned from lunch and my session had > >> timed > >> >> out. I hit the SAVE button on a form and it redirected me to our > >> login > >> >> page. > >> >> > > >> >> > But prior to logging back in; I checked the database and > noticed > >> that > >> >> the record was in fact persisted with the changes from the form. > >> All I > >> >> can gather is the following: > >> >> > > >> >> > 1. Request comes in for Struts > >> >> > 2. Hibernate Session opened via OSIV > >> >> > 3. Model is loaded from DB via prepare() > >> >> > 4. Struts copies parameters into the model > >> >> > 5. Validation/Interceptors fire > >> >> > 6. Authentication Interceptor detects timed out session, > returns > >> >> LOGIN > >> >> > 7. User presented with login page > >> >> > 8. OSIV filter closes, changes from #4 persisted. > >> >> > > >> >> > I then created a simple test action where I load a persist > entity > >> >> from the DB in a ModelDriven action, I call the action passing > >> >> parameters that are properties on the entity. Then the execute() > >> >> method does nothing more than return SUCCESS which maps to my > >> >> /pages/done.jsp. The changes are committed. > >> >> > > >> >> > I'd prefer that changes aren't committed unless I explicitly > call > >> to > >> >> do so on the EntityManager; however I understand Hibernate/JPA's > >> >> reasons behind why it works the way it does. > >> >> > > >> >> > > >> >> > > >> >> >> -Original Message- > >> >> >> From: François Rouxel [mailto:rouxe...@yahoo.com] > >> >> >> Sent: Wednesday, March 09, 2011 12:24 PM > >> >> >> To: Struts Users Mailing List > >> >> >> Subject: Re : Re : ModelDriven & Hibernate Entities > >> >> >> > >> >> &
RE: RE: Re : Re : ModelDriven & Hibernate Entities
Oh, learn something new every day :) > -Original Message- > From: Dave Newton [mailto:davelnew...@gmail.com] > Sent: Thursday, March 10, 2011 10:40 AM > To: CRANFORD, CHRIS > Cc: Struts Users Mailing List; Maurizio Cucchiara > Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities > > On Thu, Mar 10, 2011 at 11:38 AM, CRANFORD, CHRIS wrote: > > Yes the plugin is in the app's lib directory. > > Just FYI, that sets the object factory to "spring", so Spring is > instantiating your actions. > > (At least it used to.) > > Dave - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: RE: Re : Re : ModelDriven & Hibernate Entities
On Thu, Mar 10, 2011 at 11:38 AM, CRANFORD, CHRIS wrote: > Yes the plugin is in the app's lib directory. Just FYI, that sets the object factory to "spring", so Spring is instantiating your actions. (At least it used to.) Dave - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
RE: RE: Re : Re : ModelDriven & Hibernate Entities
Dave - Yes the plugin is in the app's lib directory. > -Original Message- > From: Dave Newton [mailto:davelnew...@gmail.com] > Sent: Thursday, March 10, 2011 10:37 AM > To: Struts Users Mailing List > Cc: CRANFORD, CHRIS; Maurizio Cucchiara > Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities > > On Thu, Mar 10, 2011 at 11:32 AM, CRANFORD, CHRIS wrote: > > I don't use Spring to instantiate my actions, they're not defined > like that. > > And you're not using the S2 Spring plugin? (Just for the sake of > completeness; I'm only marginally following this thread.) > > Dave - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: RE: Re : Re : ModelDriven & Hibernate Entities
On Thu, Mar 10, 2011 at 11:32 AM, CRANFORD, CHRIS wrote: > I don't use Spring to instantiate my actions, they're not defined like that. And you're not using the S2 Spring plugin? (Just for the sake of completeness; I'm only marginally following this thread.) Dave - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
RE: RE: Re : Re : ModelDriven & Hibernate Entities
I don't use Spring to instantiate my actions, they're not defined like that. Spring injects my services into my actions because I use the @Autowired annotation. I then have all my services and DAO classes annotated with the @Service and @Repository annotations so that I can wire then through injection. But each action instance itself is instantiated by Struts itself and not Spring. The only other things that I have spring managing is the transactions and security. > -Original Message- > From: Maurizio Cucchiara [mailto:maurizio.cucchi...@gmail.com] > Sent: Thursday, March 10, 2011 1:41 AM > To: Struts Users Mailing List > Cc: CRANFORD, CHRIS > Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities > > It's exactly what I meant (you can leave in your service class too). > The object factory must be spring and your class name inside the > action configuration must contain the bean id (instead of the real > class name). > I'm not sure if it works but it worth a try though. > > On 10 March 2011 00:08, CRANFORD, CHRIS > wrote: > > In the Struts2 Action rather than my service class? > > > >> -Original Message- > >> From: Maurizio Cucchiara [mailto:maurizio.cucchi...@gmail.com] > >> Sent: Wednesday, March 09, 2011 4:20 PM > >> To: Struts Users Mailing List > >> Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities > >> > >> Have you tried to put the transational annotation in the class > >> declaration? > >> > >> Maurizio Cucchiara > >> > >> Il giorno 09/mar/2011 21.38, "CRANFORD, CHRIS" > >> > >> ha scritto: > >> > I still think this is related to my @Transactional annotation > maybe. > >> > > >> >> -Original Message- > >> >> From: Dave Newton [mailto:davelnew...@gmail.com] > >> >> Sent: Wednesday, March 09, 2011 2:16 PM > >> >> To: Struts Users Mailing List > >> >> Subject: Re: Re : Re : ModelDriven & Hibernate Entities > >> >> > >> >> Another reason OSiV filters can be tricky. > >> >> > >> >> Dave > >> >> > >> >> On Wed, Mar 9, 2011 at 2:04 PM, CRANFORD, CHRIS > >> >> wrote: > >> >> > Francois - > >> >> > > >> >> > I use the standard paramsPrepareParamsStack interceptor from > >> Struts. > >> >> > > >> >> > All I have done on my end is wrap this interceptor stack with a > >> few > >> >> application specific interceptors that control things such as > >> >> authentication required, auditing, and logging. I stepped upon > my > >> >> issue one day when I had returned from lunch and my session had > >> timed > >> >> out. I hit the SAVE button on a form and it redirected me to our > >> login > >> >> page. > >> >> > > >> >> > But prior to logging back in; I checked the database and > noticed > >> that > >> >> the record was in fact persisted with the changes from the form. > >> All I > >> >> can gather is the following: > >> >> > > >> >> > 1. Request comes in for Struts > >> >> > 2. Hibernate Session opened via OSIV > >> >> > 3. Model is loaded from DB via prepare() > >> >> > 4. Struts copies parameters into the model > >> >> > 5. Validation/Interceptors fire > >> >> > 6. Authentication Interceptor detects timed out session, > returns > >> >> LOGIN > >> >> > 7. User presented with login page > >> >> > 8. OSIV filter closes, changes from #4 persisted. > >> >> > > >> >> > I then created a simple test action where I load a persist > entity > >> >> from the DB in a ModelDriven action, I call the action passing > >> >> parameters that are properties on the entity. Then the execute() > >> >> method does nothing more than return SUCCESS which maps to my > >> >> /pages/done.jsp. The changes are committed. > >> >> > > >> >> > I'd prefer that changes aren't committed unless I explicitly > call > >> to > >> >> do so on the EntityManager; however I understand Hibernate/JPA's > >> >> reasons behind why it
RE: Re : Re : ModelDriven & Hibernate Entities
Martin -
This is what has me confused. I don't believe that Hibernate's FLUSHMODE is
even being set and I am starting to question if that is because of how I am
using JPA in conjunction with Hibernate with Spring's transaction management
system.
I question if this is because I am using the JpaTransactionManager?
I checked Hibernate's FlushMode and it's being set to AUTO.
> -Original Message-
> From: Martin Gainty [mailto:mgai...@hotmail.com]
> Sent: Wednesday, March 09, 2011 9:59 PM
> To: Struts Users Mailing List
> Subject: RE: Re : Re : ModelDriven & Hibernate Entities
>
>
> osiv filter (should) set flushing to never (now manual) to prevent
> accidental writes on the session so
>
> Map properties = new HashMap();
> properties.put( "org.hibernate.flushMode", "manual" );
> javax.persistence.EntityManager em = createEntityManager(
> properties );
> em.getTransaction().begin();
>
> /* * always reopen a new EM and clse the existing one*/
> protected EntityManager createEntityManager(Map properties) {
> if ( em != null && em.isOpen() ) {
> em.close();
> }
> em = factory.createEntityManager( properties );
> return em;
> }
>
> http://docs.jboss.org/hibernate/core/3.2/api/org/hibernate/FlushMode.ht
> ml
>
> Martin
> __
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de
> confidentialité
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
> unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig.
> Diese Nachricht dient lediglich dem Austausch von Informationen und
> entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten
> Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt
> uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas
> le destinataire prévu, nous te demandons avec bonté que pour satisfaire
> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la
> copie de ceci est interdite. Ce message sert à l'information seulement
> et n'aura pas n'importe quel effet légalement obligatoire. Étant donné
> que les email peuvent facilement être sujets à la manipulation, nous ne
> pouvons accepter aucune responsabilité pour le contenu fourni.
>
>
>
>
> > Subject: RE: RE: Re : Re : ModelDriven & Hibernate Entities
> > Date: Wed, 9 Mar 2011 17:08:01 -0600
> > From: chris.cranf...@setech.com
> > To: user@struts.apache.org
> >
> > In the Struts2 Action rather than my service class?
> >
> > > -Original Message-
> > > From: Maurizio Cucchiara [mailto:maurizio.cucchi...@gmail.com]
> > > Sent: Wednesday, March 09, 2011 4:20 PM
> > > To: Struts Users Mailing List
> > > Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities
> > >
> > > Have you tried to put the transational annotation in the class
> > > declaration?
> > >
> > > Maurizio Cucchiara
> > >
> > > Il giorno 09/mar/2011 21.38, "CRANFORD, CHRIS"
> > >
> > > ha scritto:
> > > > I still think this is related to my @Transactional annotation
> maybe.
> > > >
> > > >> -Original Message-
> > > >> From: Dave Newton [mailto:davelnew...@gmail.com]
> > > >> Sent: Wednesday, March 09, 2011 2:16 PM
> > > >> To: Struts Users Mailing List
> > > >> Subject: Re: Re : Re : ModelDriven & Hibernate Entities
> > > >>
> > > >> Another reason OSiV filters can be tricky.
> > > >>
> > > >> Dave
> > > >>
> > > >> On Wed, Mar 9, 2011 at 2:04 PM, CRANFORD, CHRIS
> > > >> wrote:
> > > >> > Francois -
> > > >> >
> > > >> > I use the standard paramsPrepareParamsStack interceptor from
> > > Struts.
> > > >> >
> > > >> > All I have done on my end is wrap this interceptor stack with
> a
> > > few
> > > >> application specific interceptors that control things such as
> > > >> authentication required, auditing, and logging. I stepped upon
> my
> > > >> issue one day when I had returned from lunch and my ses
Re: RE: Re : Re : ModelDriven & Hibernate Entities
It's exactly what I meant (you can leave in your service class too). The object factory must be spring and your class name inside the action configuration must contain the bean id (instead of the real class name). I'm not sure if it works but it worth a try though. On 10 March 2011 00:08, CRANFORD, CHRIS wrote: > In the Struts2 Action rather than my service class? > >> -Original Message- >> From: Maurizio Cucchiara [mailto:maurizio.cucchi...@gmail.com] >> Sent: Wednesday, March 09, 2011 4:20 PM >> To: Struts Users Mailing List >> Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities >> >> Have you tried to put the transational annotation in the class >> declaration? >> >> Maurizio Cucchiara >> >> Il giorno 09/mar/2011 21.38, "CRANFORD, CHRIS" >> >> ha scritto: >> > I still think this is related to my @Transactional annotation maybe. >> > >> >> -Original Message- >> >> From: Dave Newton [mailto:davelnew...@gmail.com] >> >> Sent: Wednesday, March 09, 2011 2:16 PM >> >> To: Struts Users Mailing List >> >> Subject: Re: Re : Re : ModelDriven & Hibernate Entities >> >> >> >> Another reason OSiV filters can be tricky. >> >> >> >> Dave >> >> >> >> On Wed, Mar 9, 2011 at 2:04 PM, CRANFORD, CHRIS >> >> wrote: >> >> > Francois - >> >> > >> >> > I use the standard paramsPrepareParamsStack interceptor from >> Struts. >> >> > >> >> > All I have done on my end is wrap this interceptor stack with a >> few >> >> application specific interceptors that control things such as >> >> authentication required, auditing, and logging. I stepped upon my >> >> issue one day when I had returned from lunch and my session had >> timed >> >> out. I hit the SAVE button on a form and it redirected me to our >> login >> >> page. >> >> > >> >> > But prior to logging back in; I checked the database and noticed >> that >> >> the record was in fact persisted with the changes from the form. >> All I >> >> can gather is the following: >> >> > >> >> > 1. Request comes in for Struts >> >> > 2. Hibernate Session opened via OSIV >> >> > 3. Model is loaded from DB via prepare() >> >> > 4. Struts copies parameters into the model >> >> > 5. Validation/Interceptors fire >> >> > 6. Authentication Interceptor detects timed out session, returns >> >> LOGIN >> >> > 7. User presented with login page >> >> > 8. OSIV filter closes, changes from #4 persisted. >> >> > >> >> > I then created a simple test action where I load a persist entity >> >> from the DB in a ModelDriven action, I call the action passing >> >> parameters that are properties on the entity. Then the execute() >> >> method does nothing more than return SUCCESS which maps to my >> >> /pages/done.jsp. The changes are committed. >> >> > >> >> > I'd prefer that changes aren't committed unless I explicitly call >> to >> >> do so on the EntityManager; however I understand Hibernate/JPA's >> >> reasons behind why it works the way it does. >> >> > >> >> > >> >> > >> >> >> -Original Message- >> >> >> From: François Rouxel [mailto:rouxe...@yahoo.com] >> >> >> Sent: Wednesday, March 09, 2011 12:24 PM >> >> >> To: Struts Users Mailing List >> >> >> Subject: Re : Re : ModelDriven & Hibernate Entities >> >> >> >> >> >> Hi Chris, >> >> >> first, >> >> >> you might have another pb, because struts2 does not change your >> >> model >> >> >> if a >> >> >> validation failed. In may case, the model is not changed so not >> >> >> persisted. Do u >> >> >> use validation and workflow interceptor ? >> >> >> second, >> >> >> you are right about MVC pattern, but, just be aware that when you >> >> use >> >> >> OSIV >> >> >> pattern, hibernate call backend service when loading data...:-)) >> so >> >> >> your JSP is >> >> >> not just a view in that case >> >> >>
RE: Re : Re : ModelDriven & Hibernate Entities
osiv filter (should) set flushing to never (now manual) to prevent accidental
writes on the session so
Map properties = new HashMap();
properties.put( "org.hibernate.flushMode", "manual" );
javax.persistence.EntityManager em = createEntityManager( properties );
em.getTransaction().begin();
/* * always reopen a new EM and clse the existing one*/
protected EntityManager createEntityManager(Map properties) {
if ( em != null && em.isOpen() ) {
em.close();
}
em = factory.createEntityManager( properties );
return em;
}
http://docs.jboss.org/hibernate/core/3.2/api/org/hibernate/FlushMode.html
Martin
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
> Subject: RE: RE: Re : Re : ModelDriven & Hibernate Entities
> Date: Wed, 9 Mar 2011 17:08:01 -0600
> From: chris.cranf...@setech.com
> To: user@struts.apache.org
>
> In the Struts2 Action rather than my service class?
>
> > -Original Message-
> > From: Maurizio Cucchiara [mailto:maurizio.cucchi...@gmail.com]
> > Sent: Wednesday, March 09, 2011 4:20 PM
> > To: Struts Users Mailing List
> > Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities
> >
> > Have you tried to put the transational annotation in the class
> > declaration?
> >
> > Maurizio Cucchiara
> >
> > Il giorno 09/mar/2011 21.38, "CRANFORD, CHRIS"
> >
> > ha scritto:
> > > I still think this is related to my @Transactional annotation maybe.
> > >
> > >> -Original Message-
> > >> From: Dave Newton [mailto:davelnew...@gmail.com]
> > >> Sent: Wednesday, March 09, 2011 2:16 PM
> > >> To: Struts Users Mailing List
> > >> Subject: Re: Re : Re : ModelDriven & Hibernate Entities
> > >>
> > >> Another reason OSiV filters can be tricky.
> > >>
> > >> Dave
> > >>
> > >> On Wed, Mar 9, 2011 at 2:04 PM, CRANFORD, CHRIS
> > >> wrote:
> > >> > Francois -
> > >> >
> > >> > I use the standard paramsPrepareParamsStack interceptor from
> > Struts.
> > >> >
> > >> > All I have done on my end is wrap this interceptor stack with a
> > few
> > >> application specific interceptors that control things such as
> > >> authentication required, auditing, and logging. I stepped upon my
> > >> issue one day when I had returned from lunch and my session had
> > timed
> > >> out. I hit the SAVE button on a form and it redirected me to our
> > login
> > >> page.
> > >> >
> > >> > But prior to logging back in; I checked the database and noticed
> > that
> > >> the record was in fact persisted with the changes from the form.
> > All I
> > >> can gather is the following:
> > >> >
> > >> > 1. Request comes in for Struts
> > >> > 2. Hibernate Session opened via OSIV
> > >> > 3. Model is loaded from DB via prepare()
> > >> > 4. Struts copies parameters into the model
> > >> > 5. Validation/Interceptors fire
> > >> > 6. Authentication Interceptor detects timed out session, returns
> > >> LOGIN
> > >> > 7. User presented with login page
> > >> > 8. OSIV filter closes, changes from #4 persisted.
> > >> >
> > >> > I then created a simple test action where I load a persist entity
> > >> from the DB in a ModelDriven action, I call the action passing
> > >> parameters that are proper
RE: RE: Re : Re : ModelDriven & Hibernate Entities
In the Struts2 Action rather than my service class? > -Original Message- > From: Maurizio Cucchiara [mailto:maurizio.cucchi...@gmail.com] > Sent: Wednesday, March 09, 2011 4:20 PM > To: Struts Users Mailing List > Subject: Re: RE: Re : Re : ModelDriven & Hibernate Entities > > Have you tried to put the transational annotation in the class > declaration? > > Maurizio Cucchiara > > Il giorno 09/mar/2011 21.38, "CRANFORD, CHRIS" > > ha scritto: > > I still think this is related to my @Transactional annotation maybe. > > > >> -Original Message- > >> From: Dave Newton [mailto:davelnew...@gmail.com] > >> Sent: Wednesday, March 09, 2011 2:16 PM > >> To: Struts Users Mailing List > >> Subject: Re: Re : Re : ModelDriven & Hibernate Entities > >> > >> Another reason OSiV filters can be tricky. > >> > >> Dave > >> > >> On Wed, Mar 9, 2011 at 2:04 PM, CRANFORD, CHRIS > >> wrote: > >> > Francois - > >> > > >> > I use the standard paramsPrepareParamsStack interceptor from > Struts. > >> > > >> > All I have done on my end is wrap this interceptor stack with a > few > >> application specific interceptors that control things such as > >> authentication required, auditing, and logging. I stepped upon my > >> issue one day when I had returned from lunch and my session had > timed > >> out. I hit the SAVE button on a form and it redirected me to our > login > >> page. > >> > > >> > But prior to logging back in; I checked the database and noticed > that > >> the record was in fact persisted with the changes from the form. > All I > >> can gather is the following: > >> > > >> > 1. Request comes in for Struts > >> > 2. Hibernate Session opened via OSIV > >> > 3. Model is loaded from DB via prepare() > >> > 4. Struts copies parameters into the model > >> > 5. Validation/Interceptors fire > >> > 6. Authentication Interceptor detects timed out session, returns > >> LOGIN > >> > 7. User presented with login page > >> > 8. OSIV filter closes, changes from #4 persisted. > >> > > >> > I then created a simple test action where I load a persist entity > >> from the DB in a ModelDriven action, I call the action passing > >> parameters that are properties on the entity. Then the execute() > >> method does nothing more than return SUCCESS which maps to my > >> /pages/done.jsp. The changes are committed. > >> > > >> > I'd prefer that changes aren't committed unless I explicitly call > to > >> do so on the EntityManager; however I understand Hibernate/JPA's > >> reasons behind why it works the way it does. > >> > > >> > > >> > > >> >> -Original Message- > >> >> From: François Rouxel [mailto:rouxe...@yahoo.com] > >> >> Sent: Wednesday, March 09, 2011 12:24 PM > >> >> To: Struts Users Mailing List > >> >> Subject: Re : Re : ModelDriven & Hibernate Entities > >> >> > >> >> Hi Chris, > >> >> first, > >> >> you might have another pb, because struts2 does not change your > >> model > >> >> if a > >> >> validation failed. In may case, the model is not changed so not > >> >> persisted. Do u > >> >> use validation and workflow interceptor ? > >> >> second, > >> >> you are right about MVC pattern, but, just be aware that when you > >> use > >> >> OSIV > >> >> pattern, hibernate call backend service when loading data...:-)) > so > >> >> your JSP is > >> >> not just a view in that case > >> >> > >> >> > >> >> I wrote my first mail thinking you wanna rollback after an > exception > >> >> occured. > >> >> maybe it's gonna help others. > >> >> > >> >> fr/ > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> - Message d'origine > >> >> De : "CRANFORD, CHRIS" > >> >> À : Struts Users Mailing List > >> >> Envoy
Re: RE: Re : Re : ModelDriven & Hibernate Entities
Have you tried to put the transational annotation in the class declaration? Maurizio Cucchiara Il giorno 09/mar/2011 21.38, "CRANFORD, CHRIS" ha scritto: > I still think this is related to my @Transactional annotation maybe. > >> -Original Message- >> From: Dave Newton [mailto:davelnew...@gmail.com] >> Sent: Wednesday, March 09, 2011 2:16 PM >> To: Struts Users Mailing List >> Subject: Re: Re : Re : ModelDriven & Hibernate Entities >> >> Another reason OSiV filters can be tricky. >> >> Dave >> >> On Wed, Mar 9, 2011 at 2:04 PM, CRANFORD, CHRIS >> wrote: >> > Francois - >> > >> > I use the standard paramsPrepareParamsStack interceptor from Struts. >> > >> > All I have done on my end is wrap this interceptor stack with a few >> application specific interceptors that control things such as >> authentication required, auditing, and logging. I stepped upon my >> issue one day when I had returned from lunch and my session had timed >> out. I hit the SAVE button on a form and it redirected me to our login >> page. >> > >> > But prior to logging back in; I checked the database and noticed that >> the record was in fact persisted with the changes from the form. All I >> can gather is the following: >> > >> > 1. Request comes in for Struts >> > 2. Hibernate Session opened via OSIV >> > 3. Model is loaded from DB via prepare() >> > 4. Struts copies parameters into the model >> > 5. Validation/Interceptors fire >> > 6. Authentication Interceptor detects timed out session, returns >> LOGIN >> > 7. User presented with login page >> > 8. OSIV filter closes, changes from #4 persisted. >> > >> > I then created a simple test action where I load a persist entity >> from the DB in a ModelDriven action, I call the action passing >> parameters that are properties on the entity. Then the execute() >> method does nothing more than return SUCCESS which maps to my >> /pages/done.jsp. The changes are committed. >> > >> > I'd prefer that changes aren't committed unless I explicitly call to >> do so on the EntityManager; however I understand Hibernate/JPA's >> reasons behind why it works the way it does. >> > >> > >> > >> >> -Original Message- >> >> From: François Rouxel [mailto:rouxe...@yahoo.com] >> >> Sent: Wednesday, March 09, 2011 12:24 PM >> >> To: Struts Users Mailing List >> >> Subject: Re : Re : ModelDriven & Hibernate Entities >> >> >> >> Hi Chris, >> >> first, >> >> you might have another pb, because struts2 does not change your >> model >> >> if a >> >> validation failed. In may case, the model is not changed so not >> >> persisted. Do u >> >> use validation and workflow interceptor ? >> >> second, >> >> you are right about MVC pattern, but, just be aware that when you >> use >> >> OSIV >> >> pattern, hibernate call backend service when loading data...:-)) so >> >> your JSP is >> >> not just a view in that case >> >> >> >> >> >> I wrote my first mail thinking you wanna rollback after an exception >> >> occured. >> >> maybe it's gonna help others. >> >> >> >> fr/ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> - Message d'origine >> >> De : "CRANFORD, CHRIS" >> >> À : Struts Users Mailing List >> >> Envoyé le : Mer 9 mars 2011, 13h 09min 33s >> >> Objet : RE: Re : ModelDriven & Hibernate Entities >> >> >> >> Francois - >> >> >> >> While that may work for you, I wouldn't place anything Hibernate or >> >> persistence >> >> related in my JSP pages at all. In my mind, this breaks the entire >> >> reasoning >> >> behind MVC and the view simply there to render data. If the view is >> >> doing >> >> anything beyond that, I have a design problem, but again that's my >> >> opinion. >> >> >> >> But what about when you use the INPUT result code in your execute() >> >> method. >> >> >> >> If I return the user to
RE: Re : Re : ModelDriven & Hibernate Entities
I still think this is related to my @Transactional annotation maybe. > -Original Message- > From: Dave Newton [mailto:davelnew...@gmail.com] > Sent: Wednesday, March 09, 2011 2:16 PM > To: Struts Users Mailing List > Subject: Re: Re : Re : ModelDriven & Hibernate Entities > > Another reason OSiV filters can be tricky. > > Dave > > On Wed, Mar 9, 2011 at 2:04 PM, CRANFORD, CHRIS > wrote: > > Francois - > > > > I use the standard paramsPrepareParamsStack interceptor from Struts. > > > > All I have done on my end is wrap this interceptor stack with a few > application specific interceptors that control things such as > authentication required, auditing, and logging. I stepped upon my > issue one day when I had returned from lunch and my session had timed > out. I hit the SAVE button on a form and it redirected me to our login > page. > > > > But prior to logging back in; I checked the database and noticed that > the record was in fact persisted with the changes from the form. All I > can gather is the following: > > > > 1. Request comes in for Struts > > 2. Hibernate Session opened via OSIV > > 3. Model is loaded from DB via prepare() > > 4. Struts copies parameters into the model > > 5. Validation/Interceptors fire > > 6. Authentication Interceptor detects timed out session, returns > LOGIN > > 7. User presented with login page > > 8. OSIV filter closes, changes from #4 persisted. > > > > I then created a simple test action where I load a persist entity > from the DB in a ModelDriven action, I call the action passing > parameters that are properties on the entity. Then the execute() > method does nothing more than return SUCCESS which maps to my > /pages/done.jsp. The changes are committed. > > > > I'd prefer that changes aren't committed unless I explicitly call to > do so on the EntityManager; however I understand Hibernate/JPA's > reasons behind why it works the way it does. > > > > > > > >> -Original Message- > >> From: François Rouxel [mailto:rouxe...@yahoo.com] > >> Sent: Wednesday, March 09, 2011 12:24 PM > >> To: Struts Users Mailing List > >> Subject: Re : Re : ModelDriven & Hibernate Entities > >> > >> Hi Chris, > >> first, > >> you might have another pb, because struts2 does not change your > model > >> if a > >> validation failed. In may case, the model is not changed so not > >> persisted. Do u > >> use validation and workflow interceptor ? > >> second, > >> you are right about MVC pattern, but, just be aware that when you > use > >> OSIV > >> pattern, hibernate call backend service when loading data...:-)) so > >> your JSP is > >> not just a view in that case > >> > >> > >> I wrote my first mail thinking you wanna rollback after an exception > >> occured. > >> maybe it's gonna help others. > >> > >> fr/ > >> > >> > >> > >> > >> > >> > >> > >> - Message d'origine > >> De : "CRANFORD, CHRIS" > >> À : Struts Users Mailing List > >> Envoyé le : Mer 9 mars 2011, 13h 09min 33s > >> Objet : RE: Re : ModelDriven & Hibernate Entities > >> > >> Francois - > >> > >> While that may work for you, I wouldn't place anything Hibernate or > >> persistence > >> related in my JSP pages at all. In my mind, this breaks the entire > >> reasoning > >> behind MVC and the view simply there to render data. If the view is > >> doing > >> anything beyond that, I have a design problem, but again that's my > >> opinion. > >> > >> But what about when you use the INPUT result code in your execute() > >> method. > >> > >> If I return the user to the INPUT method because maybe I'm not using > >> the Struts > >> validation framework and doing it myself in my execute() method or I > >> have some > >> complex conditions I must check for before I save the data. In this > >> case, by > >> returning INPUT and setting some action field or error messages to > be > >> shown to > >> the user, the error exception handler isn't fired, thus your > rollback > >> isn't > >> fired either; leaving your entity persisted with likely d
Re: Re : Re : ModelDriven & Hibernate Entities
Another reason OSiV filters can be tricky.
Dave
On Wed, Mar 9, 2011 at 2:04 PM, CRANFORD, CHRIS
wrote:
> Francois -
>
> I use the standard paramsPrepareParamsStack interceptor from Struts.
>
> All I have done on my end is wrap this interceptor stack with a few
> application specific interceptors that control things such as authentication
> required, auditing, and logging. I stepped upon my issue one day when I had
> returned from lunch and my session had timed out. I hit the SAVE button on a
> form and it redirected me to our login page.
>
> But prior to logging back in; I checked the database and noticed that the
> record was in fact persisted with the changes from the form. All I can
> gather is the following:
>
> 1. Request comes in for Struts
> 2. Hibernate Session opened via OSIV
> 3. Model is loaded from DB via prepare()
> 4. Struts copies parameters into the model
> 5. Validation/Interceptors fire
> 6. Authentication Interceptor detects timed out session, returns LOGIN
> 7. User presented with login page
> 8. OSIV filter closes, changes from #4 persisted.
>
> I then created a simple test action where I load a persist entity from the DB
> in a ModelDriven action, I call the action passing parameters that are
> properties on the entity. Then the execute() method does nothing more than
> return SUCCESS which maps to my /pages/done.jsp. The changes are committed.
>
> I'd prefer that changes aren't committed unless I explicitly call to do so on
> the EntityManager; however I understand Hibernate/JPA's reasons behind why it
> works the way it does.
>
>
>
>> -Original Message-
>> From: François Rouxel [mailto:rouxe...@yahoo.com]
>> Sent: Wednesday, March 09, 2011 12:24 PM
>> To: Struts Users Mailing List
>> Subject: Re : Re : ModelDriven & Hibernate Entities
>>
>> Hi Chris,
>> first,
>> you might have another pb, because struts2 does not change your model
>> if a
>> validation failed. In may case, the model is not changed so not
>> persisted. Do u
>> use validation and workflow interceptor ?
>> second,
>> you are right about MVC pattern, but, just be aware that when you use
>> OSIV
>> pattern, hibernate call backend service when loading data...:-)) so
>> your JSP is
>> not just a view in that case
>>
>>
>> I wrote my first mail thinking you wanna rollback after an exception
>> occured.
>> maybe it's gonna help others.
>>
>> fr/
>>
>>
>>
>>
>>
>>
>>
>> - Message d'origine
>> De : "CRANFORD, CHRIS"
>> À : Struts Users Mailing List
>> Envoyé le : Mer 9 mars 2011, 13h 09min 33s
>> Objet : RE: Re : ModelDriven & Hibernate Entities
>>
>> Francois -
>>
>> While that may work for you, I wouldn't place anything Hibernate or
>> persistence
>> related in my JSP pages at all. In my mind, this breaks the entire
>> reasoning
>> behind MVC and the view simply there to render data. If the view is
>> doing
>> anything beyond that, I have a design problem, but again that's my
>> opinion.
>>
>> But what about when you use the INPUT result code in your execute()
>> method.
>>
>> If I return the user to the INPUT method because maybe I'm not using
>> the Struts
>> validation framework and doing it myself in my execute() method or I
>> have some
>> complex conditions I must check for before I save the data. In this
>> case, by
>> returning INPUT and setting some action field or error messages to be
>> shown to
>> the user, the error exception handler isn't fired, thus your rollback
>> isn't
>> fired either; leaving your entity persisted with likely dirty data.
>>
>> > -Original Message-
>> > From: François Rouxel [mailto:rouxe...@yahoo.com]
>> > Sent: Wednesday, March 09, 2011 11:43 AM
>> > To: Struts Users Mailing List
>> > Subject: Re : ModelDriven & Hibernate Entities
>> >
>> > same issue
>> > this how I fixed it : (the main idea is to redirect to a jsp if an
>> > exception
>> > occured, and the jsp rollback)
>> >
>> > create an error page error.jsp
>> > <%@page import="com.rdvcentral.util.persistance.HibernateUtil"%>
>> > <%@ page contentType="text/html;charset=UTF-8" language="java" %>
>> > <%@ taglib prefix="s" uri="/struts-tags" %>
>> > <%@ taglib prefix="sj" uri="/struts-jquery-tags" %>
>> >
>> >
>> > <%@page import="org.hibernate.Transaction"%>
>> > <%@page import="org.apache.log4j.Logger"%>
>> >
>> >
>> > <%
>> > Transaction tx = new
>> >
>> HibernateUtil().getSessionFactory().getCurrentSession().getTransaction(
>> > );
>> > if (tx != null && tx.isActive()) {
>> > tx.rollback();
>> > }
>> > %>
>> >
>> > In your struts mapping file :
>> >
>> >
>> > /error.jsp
>> >
>> >
>> >
>> >
>> > > > result="unhandledException" />
>> >
>> >
>> > hope it will help you
>> >
>> >
>> >
>> >
>> >
RE: Re : Re : ModelDriven & Hibernate Entities
Yes, that was the issue, it was interceptor order related. Now if only I could get the persistent entity not to be flushed under specific conditions: - Exception - Non-SUCCESS return code, etc. > -Original Message- > From: Chris Pratt [mailto:thechrispr...@gmail.com] > Sent: Wednesday, March 09, 2011 1:35 PM > To: Struts Users Mailing List > Subject: Re: Re : Re : ModelDriven & Hibernate Entities > > It might just be an order of interceptors problem. One of your first > interceptors should be your login check. That should definitely happen > before the standard paramsPrepareParamsStack is run. > (*Chris*) > > On Wed, Mar 9, 2011 at 11:04 AM, CRANFORD, CHRIS > wrote: > > > Francois - > > > > I use the standard paramsPrepareParamsStack interceptor from Struts. > > > > All I have done on my end is wrap this interceptor stack with a few > > application specific interceptors that control things such as > authentication > > required, auditing, and logging. I stepped upon my issue one day > when I had > > returned from lunch and my session had timed out. I hit the SAVE > button on > > a form and it redirected me to our login page. > > > > But prior to logging back in; I checked the database and noticed that > the > > record was in fact persisted with the changes from the form. All I > can > > gather is the following: > > > > 1. Request comes in for Struts > > 2. Hibernate Session opened via OSIV > > 3. Model is loaded from DB via prepare() > > 4. Struts copies parameters into the model > > 5. Validation/Interceptors fire > > 6. Authentication Interceptor detects timed out session, returns > LOGIN > > 7. User presented with login page > > 8. OSIV filter closes, changes from #4 persisted. > > > > I then created a simple test action where I load a persist entity > from the > > DB in a ModelDriven action, I call the action passing parameters that > are > > properties on the entity. Then the execute() method does nothing > more than > > return SUCCESS which maps to my /pages/done.jsp. The changes are > committed. > > > > I'd prefer that changes aren't committed unless I explicitly call to > do so > > on the EntityManager; however I understand Hibernate/JPA's reasons > behind > > why it works the way it does. > > > > > > > > > -Original Message- > > > From: François Rouxel [mailto:rouxe...@yahoo.com] > > > Sent: Wednesday, March 09, 2011 12:24 PM > > > To: Struts Users Mailing List > > > Subject: Re : Re : ModelDriven & Hibernate Entities > > > > > > Hi Chris, > > > first, > > > you might have another pb, because struts2 does not change your > model > > > if a > > > validation failed. In may case, the model is not changed so not > > > persisted. Do u > > > use validation and workflow interceptor ? > > > second, > > > you are right about MVC pattern, but, just be aware that when you > use > > > OSIV > > > pattern, hibernate call backend service when loading data...:-)) so > > > your JSP is > > > not just a view in that case > > > > > > > > > I wrote my first mail thinking you wanna rollback after an > exception > > > occured. > > > maybe it's gonna help others. > > > > > > fr/ > > > > > > > > > > > > > > > > > > > > > > > > - Message d'origine > > > De : "CRANFORD, CHRIS" > > > À : Struts Users Mailing List > > > Envoyé le : Mer 9 mars 2011, 13h 09min 33s > > > Objet : RE: Re : ModelDriven & Hibernate Entities > > > > > > Francois - > > > > > > While that may work for you, I wouldn't place anything Hibernate or > > > persistence > > > related in my JSP pages at all. In my mind, this breaks the entire > > > reasoning > > > behind MVC and the view simply there to render data. If the view > is > > > doing > > > anything beyond that, I have a design problem, but again that's my > > > opinion. > > > > > > But what about when you use the INPUT result code in your execute() > > > method. > > > > > > If I return the user to the INPUT method because maybe I'm not > using > > > the Struts > > > validation framework and doing it myself in m
Re: Re : Re : ModelDriven & Hibernate Entities
It might just be an order of interceptors problem. One of your first
interceptors should be your login check. That should definitely happen
before the standard paramsPrepareParamsStack is run.
(*Chris*)
On Wed, Mar 9, 2011 at 11:04 AM, CRANFORD, CHRIS
wrote:
> Francois -
>
> I use the standard paramsPrepareParamsStack interceptor from Struts.
>
> All I have done on my end is wrap this interceptor stack with a few
> application specific interceptors that control things such as authentication
> required, auditing, and logging. I stepped upon my issue one day when I had
> returned from lunch and my session had timed out. I hit the SAVE button on
> a form and it redirected me to our login page.
>
> But prior to logging back in; I checked the database and noticed that the
> record was in fact persisted with the changes from the form. All I can
> gather is the following:
>
> 1. Request comes in for Struts
> 2. Hibernate Session opened via OSIV
> 3. Model is loaded from DB via prepare()
> 4. Struts copies parameters into the model
> 5. Validation/Interceptors fire
> 6. Authentication Interceptor detects timed out session, returns LOGIN
> 7. User presented with login page
> 8. OSIV filter closes, changes from #4 persisted.
>
> I then created a simple test action where I load a persist entity from the
> DB in a ModelDriven action, I call the action passing parameters that are
> properties on the entity. Then the execute() method does nothing more than
> return SUCCESS which maps to my /pages/done.jsp. The changes are committed.
>
> I'd prefer that changes aren't committed unless I explicitly call to do so
> on the EntityManager; however I understand Hibernate/JPA's reasons behind
> why it works the way it does.
>
>
>
> > -Original Message-
> > From: François Rouxel [mailto:rouxe...@yahoo.com]
> > Sent: Wednesday, March 09, 2011 12:24 PM
> > To: Struts Users Mailing List
> > Subject: Re : Re : ModelDriven & Hibernate Entities
> >
> > Hi Chris,
> > first,
> > you might have another pb, because struts2 does not change your model
> > if a
> > validation failed. In may case, the model is not changed so not
> > persisted. Do u
> > use validation and workflow interceptor ?
> > second,
> > you are right about MVC pattern, but, just be aware that when you use
> > OSIV
> > pattern, hibernate call backend service when loading data...:-)) so
> > your JSP is
> > not just a view in that case
> >
> >
> > I wrote my first mail thinking you wanna rollback after an exception
> > occured.
> > maybe it's gonna help others.
> >
> > fr/
> >
> >
> >
> >
> >
> >
> >
> > - Message d'origine
> > De : "CRANFORD, CHRIS"
> > À : Struts Users Mailing List
> > Envoyé le : Mer 9 mars 2011, 13h 09min 33s
> > Objet : RE: Re : ModelDriven & Hibernate Entities
> >
> > Francois -
> >
> > While that may work for you, I wouldn't place anything Hibernate or
> > persistence
> > related in my JSP pages at all. In my mind, this breaks the entire
> > reasoning
> > behind MVC and the view simply there to render data. If the view is
> > doing
> > anything beyond that, I have a design problem, but again that's my
> > opinion.
> >
> > But what about when you use the INPUT result code in your execute()
> > method.
> >
> > If I return the user to the INPUT method because maybe I'm not using
> > the Struts
> > validation framework and doing it myself in my execute() method or I
> > have some
> > complex conditions I must check for before I save the data. In this
> > case, by
> > returning INPUT and setting some action field or error messages to be
> > shown to
> > the user, the error exception handler isn't fired, thus your rollback
> > isn't
> > fired either; leaving your entity persisted with likely dirty data.
> >
> > > -Original Message-
> > > From: François Rouxel [mailto:rouxe...@yahoo.com]
> > > Sent: Wednesday, March 09, 2011 11:43 AM
> > > To: Struts Users Mailing List
> > > Subject: Re : ModelDriven & Hibernate Entities
> > >
> > > same issue
> > > this how I fixed it : (the main idea is to redirect to a jsp if an
> > > exception
> > > occured, and the jsp rollback)
> > >
> > > create an error page error.jsp
> > > <%@page import="com.rdvcentral.util.persistance.HibernateUtil"%>
> > > <%@ page contentType="text/html;charset=UTF-8" language="java" %>
> > > <%@ taglib prefix="s" uri="/struts-tags" %>
> > > <%@ taglib prefix="sj" uri="/struts-jquery-tags" %>
> > >
> > >
> > > <%@page import="org.hibernate.Transaction"%>
> > > <%@page import="org.apache.log4j.Logger"%>
> > >
> > >
> > > <%
> > > Transaction tx = new
> > >
> > HibernateUtil().getSessionFactory().getCurrentSession().getTransaction(
> > > );
> > > if (tx != null && tx.isActive()) {
> > > tx.rollback();
> > > }
> > > %>
> > >
> > > In your struts mapping file :
> > >
> > >
> > > /error.jsp
> > >
> > >
RE: Re : Re : ModelDriven & Hibernate Entities
Francois -
I use the standard paramsPrepareParamsStack interceptor from Struts.
All I have done on my end is wrap this interceptor stack with a few application
specific interceptors that control things such as authentication required,
auditing, and logging. I stepped upon my issue one day when I had returned
from lunch and my session had timed out. I hit the SAVE button on a form and
it redirected me to our login page.
But prior to logging back in; I checked the database and noticed that the
record was in fact persisted with the changes from the form. All I can gather
is the following:
1. Request comes in for Struts
2. Hibernate Session opened via OSIV
3. Model is loaded from DB via prepare()
4. Struts copies parameters into the model
5. Validation/Interceptors fire
6. Authentication Interceptor detects timed out session, returns LOGIN
7. User presented with login page
8. OSIV filter closes, changes from #4 persisted.
I then created a simple test action where I load a persist entity from the DB
in a ModelDriven action, I call the action passing parameters that are
properties on the entity. Then the execute() method does nothing more than
return SUCCESS which maps to my /pages/done.jsp. The changes are committed.
I'd prefer that changes aren't committed unless I explicitly call to do so on
the EntityManager; however I understand Hibernate/JPA's reasons behind why it
works the way it does.
> -Original Message-
> From: François Rouxel [mailto:rouxe...@yahoo.com]
> Sent: Wednesday, March 09, 2011 12:24 PM
> To: Struts Users Mailing List
> Subject: Re : Re : ModelDriven & Hibernate Entities
>
> Hi Chris,
> first,
> you might have another pb, because struts2 does not change your model
> if a
> validation failed. In may case, the model is not changed so not
> persisted. Do u
> use validation and workflow interceptor ?
> second,
> you are right about MVC pattern, but, just be aware that when you use
> OSIV
> pattern, hibernate call backend service when loading data...:-)) so
> your JSP is
> not just a view in that case
>
>
> I wrote my first mail thinking you wanna rollback after an exception
> occured.
> maybe it's gonna help others.
>
> fr/
>
>
>
>
>
>
>
> - Message d'origine
> De : "CRANFORD, CHRIS"
> À : Struts Users Mailing List
> Envoyé le : Mer 9 mars 2011, 13h 09min 33s
> Objet : RE: Re : ModelDriven & Hibernate Entities
>
> Francois -
>
> While that may work for you, I wouldn't place anything Hibernate or
> persistence
> related in my JSP pages at all. In my mind, this breaks the entire
> reasoning
> behind MVC and the view simply there to render data. If the view is
> doing
> anything beyond that, I have a design problem, but again that's my
> opinion.
>
> But what about when you use the INPUT result code in your execute()
> method.
>
> If I return the user to the INPUT method because maybe I'm not using
> the Struts
> validation framework and doing it myself in my execute() method or I
> have some
> complex conditions I must check for before I save the data. In this
> case, by
> returning INPUT and setting some action field or error messages to be
> shown to
> the user, the error exception handler isn't fired, thus your rollback
> isn't
> fired either; leaving your entity persisted with likely dirty data.
>
> > -Original Message-
> > From: François Rouxel [mailto:rouxe...@yahoo.com]
> > Sent: Wednesday, March 09, 2011 11:43 AM
> > To: Struts Users Mailing List
> > Subject: Re : ModelDriven & Hibernate Entities
> >
> > same issue
> > this how I fixed it : (the main idea is to redirect to a jsp if an
> > exception
> > occured, and the jsp rollback)
> >
> > create an error page error.jsp
> > <%@page import="com.rdvcentral.util.persistance.HibernateUtil"%>
> > <%@ page contentType="text/html;charset=UTF-8" language="java" %>
> > <%@ taglib prefix="s" uri="/struts-tags" %>
> > <%@ taglib prefix="sj" uri="/struts-jquery-tags" %>
> >
> >
> > <%@page import="org.hibernate.Transaction"%>
> > <%@page import="org.apache.log4j.Logger"%>
> >
> >
> > <%
> > Transaction tx = new
> >
> HibernateUtil().getSessionFactory().getCurrentSession().getTransaction(
> > );
> > if (tx != null && tx.isActive()) {
> > tx.rollback();
> > }
> > %>
> >
> > In your struts mapping file :
> >
> >
> > /error.jsp
> >
> >
> >
> >
> > > result="unhandledException" />
> >
> >
> > hope it will help you
> >
> >
> >
> >
> >
> >
> >
> > - Message d'origine
> > De : "CRANFORD, CHRIS"
> > À : Struts Users Mailing List
> > Envoyé le : Mer 9 mars 2011, 12h 34min 32s
> > Objet : ModelDriven & Hibernate Entities
> >
> > I had started down a path of using the ModelDriven interfa
