You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by François Rouxel <ro...@yahoo.com> on 2011/03/09 18:42:56 UTC
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"%>
<s:property value="%{logError(exception)}"/>
<%
Transaction tx = new
HibernateUtil().getSessionFactory().getCurrentSession().getTransaction();
if (tx != null && tx.isActive()) {
tx.rollback();
}
%>
In your struts mapping file :
<global-results>
<result name="unhandledException">/error.jsp</result>
</result>
</global-results>
<global-exception-mappings>
<exception-mapping exception="java.lang.Exception"
result="unhandledException" />
</global-exception-mappings>
hope it will help you
____________________________________________
____________________________________________
----- Message d'origine ----
De : "CRANFORD, CHRIS" <Ch...@setech.com>
À : Struts Users Mailing List <us...@struts.apache.org>
Envoyé le : Mer 9 mars 2011, 12h 34min 32s
Objet : ModelDriven & Hibernate Entities
I had started down a path of using the ModelDriven interface from Struts
because I find it really helps maintain a class action class without
large numbers of get/set methods for screens that contain a lot of form
fields.
However, I am finding at least with how I have attempted to approach
ModelDriven to have several drawbacks. For example, by using the OSIV
(Open Session In View) filter, I am finding that when Struts sets the
properties on the entity and afterward if an exception is thrown, caught
and handled and doesn't trigger Hibernate to actually "rollback"; the
changes are persisted which leaves my entity in a dirty inconsistent
state.
How have others solved this by using your entity domain POJOs in your
view?
Do you use them detached from the session so that you explicitly have to
merge them to the session to be persisted? If so, how do you deal with
multiple lazy loaded collections in your entity?
Or would using DTO objects from my service layer a better alternative to
insure that no data is actually persisted to the database that shouldn't
be?
---------------------------------------------------------------------
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: Re : ModelDriven & Hibernate Entities
Posted by Dave Newton <da...@gmail.com>.
On Wed, Mar 9, 2011 at 1:09 PM, CRANFORD, CHRIS wrote:
> 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
IMO OSiV filters put non-render stuff into the JSP anyway, it's just
invisible (and may lead to Really Bad performance if people aren't
paying attention).
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: RE: Re : Re : ModelDriven & Hibernate Entities
Posted by "CRANFORD, CHRIS" <Ch...@setech.com>.
Annotating @Transactional on the action didn't help.
> -----Original Message-----
> From: Maurizio Cucchiara [mailto:maurizio.cucchiara@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 <Ch...@setech.com>
> wrote:
> > In the Struts2 Action rather than my service class?
> >
> >> -----Original Message-----
> >> From: Maurizio Cucchiara [mailto:maurizio.cucchiara@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"
> >> <Ch...@setech.com>
> >> ha scritto:
> >> > I still think this is related to my @Transactional annotation
> maybe.
> >> >
> >> >> -----Original Message-----
> >> >> From: Dave Newton [mailto:davelnewton@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
> >> >> <Ch...@setech.com> 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:rouxelec@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" <Ch...@setech.com>
> >> >> >> À : Struts Users Mailing List <us...@struts.apache.org>
> >> >> >> 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:rouxelec@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"%>
> >> >> >> >
> >> >> >> > <s:property value="%{logError(exception)}"/>
> >> >> >> > <%
> >> >> >> > Transaction tx = new
> >> >> >> >
> >> >> >>
> >> >>
> >>
> HibernateUtil().getSessionFactory().getCurrentSession().getTransaction(
> >> >> >> > );
> >> >> >> > if (tx != null && tx.isActive()) {
> >> >> >> > tx.rollback();
> >> >> >> > }
> >> >> >> > %>
> >> >> >> >
> >> >> >> > In your struts mapping file :
> >> >> >> >
> >> >> >> > <global-results>
> >> >> >> > <result
> >> name="unhandledException">/error.jsp</result>
> >> >> >> > </result>
> >> >> >> > </global-results>
> >> >> >> >
> >> >> >> > <global-exception-mappings>
> >> >> >> > <exception-mapping
> exception="java.lang.Exception"
> >> >> >> > result="unhandledException" />
> >> >> >> > </global-exception-mappings>
> >> >> >> >
> >> >> >> > hope it will help you
> >> >> >> >
> >> >> >> >
> >> >> >> > ____________________________________________
> >> >> >> > ____________________________________________
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > ----- Message d'origine ----
> >> >> >> > De : "CRANFORD, CHRIS" <Ch...@setech.com>
> >> >> >> > À : Struts Users Mailing List <us...@struts.apache.org>
> >> >> >> > Envoyé le : Mer 9 mars 2011, 12h 34min 32s
> >> >> >> > Objet : ModelDriven & Hibernate Entities
> >> >> >> >
> >> >> >> > I had started down a path of using the ModelDriven interface
> >> from
> >> >> >> > Struts
> >> >> >> > because I find it really helps maintain a class action class
> >> >> without
> >> >> >> > large numbers of get/set methods for screens that contain a
> lot
> >> of
> >> >> >> form
> >> >> >> > fields.
> >> >> >> >
> >> >> >> > However, I am finding at least with how I have attempted to
> >> >> approach
> >> >> >> > ModelDriven to have several drawbacks. For example, by
> using
> >> the
> >> >> >> OSIV
> >> >> >> > (Open Session In View) filter, I am finding that when Struts
> >> sets
> >> >> the
> >> >> >> > properties on the entity and afterward if an exception is
> >> thrown,
> >> >> >> > caught
> >> >> >> > and handled and doesn't trigger Hibernate to actually
> >> "rollback";
> >> >> the
> >> >> >> > changes are persisted which leaves my entity in a dirty
> >> >> inconsistent
> >> >> >> > state.
> >> >> >> >
> >> >> >> > How have others solved this by using your entity domain
> POJOs
> >> in
> >> >> your
> >> >> >> > view?
> >> >> >> >
> >> >> >> > Do you use them detached from the session so that you
> >> explicitly
> >> >> have
> >> >> >> > to
> >> >> >> > merge them to the session to be persisted? If so, how do
> you
> >> deal
> >> >> >> with
> >> >> >> > multiple lazy loaded collections in your entity?
> >> >> >> >
> >> >> >> > Or would using DTO objects from my service layer a better
> >> >> alternative
> >> >> >> > to
> >> >> >> > insure that no data is actually persisted to the database
> that
> >> >> >> > shouldn't
> >> >> >> > be?
> >> >> >> >
> >> >> >> >
> >> >> >> > ------------------------------------------------------------
> ---
> >> ---
> >> >> ---
> >> >> >> > 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
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --------------------------------------------------------------
> ---
> >> ---
> >> >> -
> >> >> >> 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
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > ---------------------------------------------------------------
> ---
> >> ---
> >> >> > 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
> >> >>
> >> >
> >> >
> >> >
> >> > ------------------------------------------------------------------
> ---
> >> > 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
> >
> >
>
>
>
> --
> Maurizio Cucchiara
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: RE: Re : Re : ModelDriven & Hibernate Entities
Posted by Burton Rhodes <bu...@gmail.com>.
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
<Ch...@setech.com> 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:burtonrhodes@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 <bu...@gmail.com>
>> 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
>> > <Ch...@setech.com> 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:davelnewton@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-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
>>
>
>
>
> ---------------------------------------------------------------------
> 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: RE: Re : Re : ModelDriven & Hibernate Entities
Posted by "CRANFORD, CHRIS" <Ch...@setech.com>.
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:burtonrhodes@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 <bu...@gmail.com>
> 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
> > <Ch...@setech.com> 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:davelnewton@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-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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: RE: Re : Re : ModelDriven & Hibernate Entities
Posted by Burton Rhodes <bu...@gmail.com>.
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 <bu...@gmail.com> 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
> <Ch...@setech.com> 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:davelnewton@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-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: Re : Re : ModelDriven & Hibernate Entities
Posted by Martin Gainty <mg...@hotmail.com>.
he makes the accusation that Struts ParametersInterceptor specifically flushes session data to (DB) repository but this is not the case
com.opensymphony.xwork2.interceptor.ParametersInterceptor (contents):
@Override
public String doIntercept(ActionInvocation invocation) throws Exception
{
Object action = invocation.getAction();
if (!(action instanceof NoParameters))
{
ActionContext ac = invocation.getInvocationContext();
final Map<String, Object> parameters = retrieveParameters(ac);
if (LOG.isDebugEnabled())
{
LOG.debug("Setting params " + getParameterLogMap(parameters));
}
if (parameters != null)
{
Map<String, Object> contextMap = ac.getContextMap();
try
{
ReflectionContextState.setCreatingNullObjects(contextMap, true);
ReflectionContextState.setDenyMethodExecution(contextMap, true);
ReflectionContextState.setReportingConversionErrors(contextMap, true);
ValueStack stack = ac.getValueStack();
setParameters(action, stack, parameters);
}
finally
{
ReflectionContextState.setCreatingNullObjects(contextMap, false);
ReflectionContextState.setDenyMethodExecution(contextMap, false);
ReflectionContextState.setReportingConversionErrors(contextMap, false);
}
}
}
return invocation.invoke();
}
protected void setParameters(Object action, ValueStack stack, final Map<String, Object> parameters)
{
ParameterNameAware parameterNameAware = (action instanceof ParameterNameAware) ? (ParameterNameAware) action : null;
Map<String, Object> params;
Map<String, Object> acceptableParameters;
if (ordered)
{
params = new TreeMap<String, Object>(getOrderedComparator());
acceptableParameters = new TreeMap<String, Object>(getOrderedComparator());
params.putAll(parameters);
}
else
{
params = new TreeMap<String, Object>(parameters);
acceptableParameters = new TreeMap<String, Object>();
}
for (Map.Entry<String, Object> entry : params.entrySet())
{
String name = entry.getKey();
boolean acceptableName = acceptableName(name) && (parameterNameAware == null || parameterNameAware.acceptableParameterName(name));
if (acceptableName)
{
acceptableParameters.put(name, entry.getValue());
}
}
ValueStack newStack = valueStackFactory.createValueStack(stack);
boolean clearableStack = newStack instanceof ClearableValueStack;
if (clearableStack)
{
//if the stack's context can be cleared, do that to prevent OGNL
//from having access to objects in the stack, see XW-641
((ClearableValueStack)newStack).clearContextValues();
Map<String, Object> context = newStack.getContext();
ReflectionContextState.setCreatingNullObjects(context, true);
ReflectionContextState.setDenyMethodExecution(context, true);
ReflectionContextState.setReportingConversionErrors(context, true);
//keep locale from original context
context.put(ActionContext.LOCALE, stack.getContext().get(ActionContext.LOCALE));
}
boolean memberAccessStack = newStack instanceof MemberAccessValueStack;
if (memberAccessStack) {
//block or allow access to properties
//see WW-2761 for more details
MemberAccessValueStack accessValueStack = (MemberAccessValueStack) newStack;
accessValueStack.setAcceptProperties(acceptParams);
accessValueStack.setExcludeProperties(excludeParams);
}
for (Map.Entry<String, Object> entry : acceptableParameters.entrySet()) {
String name = entry.getKey();
Object value = entry.getValue();
try {
newStack.setValue(name, value);
} catch (RuntimeException e) {
if (devMode) {
String developerNotification = LocalizedTextUtil.findText(ParametersInterceptor.class, "devmode.notification", ActionContext.getContext().getLocale(), "Developer Notification:\n{0}", new Object[]{
"Unexpected Exception caught setting '" + name + "' on '" + action.getClass() + ": " + e.getMessage()
});
LOG.error(developerNotification);
if (action instanceof ValidationAware) {
((ValidationAware) action).addActionMessage(developerNotification);
}
}
}
}
if (clearableStack && (stack.getContext() != null) && (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<String, Object> 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: burtonrhodes@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
> <Ch...@setech.com> 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:davelnewton@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-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: RE: Re : Re : ModelDriven & Hibernate Entities
Posted by Burton Rhodes <bu...@gmail.com>.
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
<Ch...@setech.com> 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:davelnewton@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-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: RE: Re : Re : ModelDriven & Hibernate Entities
Posted by "CRANFORD, CHRIS" <Ch...@setech.com>.
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:davelnewton@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: RE: Re : Re : ModelDriven & Hibernate Entities
Posted by "CRANFORD, CHRIS" <Ch...@setech.com>.
Oh, learn something new every day :)
> -----Original Message-----
> From: Dave Newton [mailto:davelnewton@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: RE: Re : Re : ModelDriven & Hibernate Entities
Posted by Dave Newton <da...@gmail.com>.
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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: RE: Re : Re : ModelDriven & Hibernate Entities
Posted by "CRANFORD, CHRIS" <Ch...@setech.com>.
Dave -
Yes the plugin is in the app's lib directory.
> -----Original Message-----
> From: Dave Newton [mailto:davelnewton@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: RE: Re : Re : ModelDriven & Hibernate Entities
Posted by Dave Newton <da...@gmail.com>.
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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: RE: Re : Re : ModelDriven & Hibernate Entities
Posted by "CRANFORD, CHRIS" <Ch...@setech.com>.
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.cucchiara@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 <Ch...@setech.com>
> wrote:
> > In the Struts2 Action rather than my service class?
> >
> >> -----Original Message-----
> >> From: Maurizio Cucchiara [mailto:maurizio.cucchiara@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"
> >> <Ch...@setech.com>
> >> ha scritto:
> >> > I still think this is related to my @Transactional annotation
> maybe.
> >> >
> >> >> -----Original Message-----
> >> >> From: Dave Newton [mailto:davelnewton@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
> >> >> <Ch...@setech.com> 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:rouxelec@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" <Ch...@setech.com>
> >> >> >> À : Struts Users Mailing List <us...@struts.apache.org>
> >> >> >> 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:rouxelec@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"%>
> >> >> >> >
> >> >> >> > <s:property value="%{logError(exception)}"/>
> >> >> >> > <%
> >> >> >> > Transaction tx = new
> >> >> >> >
> >> >> >>
> >> >>
> >>
> HibernateUtil().getSessionFactory().getCurrentSession().getTransaction(
> >> >> >> > );
> >> >> >> > if (tx != null && tx.isActive()) {
> >> >> >> > tx.rollback();
> >> >> >> > }
> >> >> >> > %>
> >> >> >> >
> >> >> >> > In your struts mapping file :
> >> >> >> >
> >> >> >> > <global-results>
> >> >> >> > <result
> >> name="unhandledException">/error.jsp</result>
> >> >> >> > </result>
> >> >> >> > </global-results>
> >> >> >> >
> >> >> >> > <global-exception-mappings>
> >> >> >> > <exception-mapping
> exception="java.lang.Exception"
> >> >> >> > result="unhandledException" />
> >> >> >> > </global-exception-mappings>
> >> >> >> >
> >> >> >> > hope it will help you
> >> >> >> >
> >> >> >> >
> >> >> >> > ____________________________________________
> >> >> >> > ____________________________________________
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > ----- Message d'origine ----
> >> >> >> > De : "CRANFORD, CHRIS" <Ch...@setech.com>
> >> >> >> > À : Struts Users Mailing List <us...@struts.apache.org>
> >> >> >> > Envoyé le : Mer 9 mars 2011, 12h 34min 32s
> >> >> >> > Objet : ModelDriven & Hibernate Entities
> >> >> >> >
> >> >> >> > I had started down a path of using the ModelDriven interface
> >> from
> >> >> >> > Struts
> >> >> >> > because I find it really helps maintain a class action class
> >> >> without
> >> >> >> > large numbers of get/set methods for screens that contain a
> lot
> >> of
> >> >> >> form
> >> >> >> > fields.
> >> >> >> >
> >> >> >> > However, I am finding at least with how I have attempted to
> >> >> approach
> >> >> >> > ModelDriven to have several drawbacks. For example, by
> using
> >> the
> >> >> >> OSIV
> >> >> >> > (Open Session In View) filter, I am finding that when Struts
> >> sets
> >> >> the
> >> >> >> > properties on the entity and afterward if an exception is
> >> thrown,
> >> >> >> > caught
> >> >> >> > and handled and doesn't trigger Hibernate to actually
> >> "rollback";
> >> >> the
> >> >> >> > changes are persisted which leaves my entity in a dirty
> >> >> inconsistent
> >> >> >> > state.
> >> >> >> >
> >> >> >> > How have others solved this by using your entity domain
> POJOs
> >> in
> >> >> your
> >> >> >> > view?
> >> >> >> >
> >> >> >> > Do you use them detached from the session so that you
> >> explicitly
> >> >> have
> >> >> >> > to
> >> >> >> > merge them to the session to be persisted? If so, how do
> you
> >> deal
> >> >> >> with
> >> >> >> > multiple lazy loaded collections in your entity?
> >> >> >> >
> >> >> >> > Or would using DTO objects from my service layer a better
> >> >> alternative
> >> >> >> > to
> >> >> >> > insure that no data is actually persisted to the database
> that
> >> >> >> > shouldn't
> >> >> >> > be?
> >> >> >> >
> >> >> >> >
> >> >> >> > ------------------------------------------------------------
> ---
> >> ---
> >> >> ---
> >> >> >> > 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
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --------------------------------------------------------------
> ---
> >> ---
> >> >> -
> >> >> >> 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
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > ---------------------------------------------------------------
> ---
> >> ---
> >> >> > 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
> >> >>
> >> >
> >> >
> >> >
> >> > ------------------------------------------------------------------
> ---
> >> > 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
> >
> >
>
>
>
> --
> Maurizio Cucchiara
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: RE: Re : Re : ModelDriven & Hibernate Entities
Posted by Maurizio Cucchiara <ma...@gmail.com>.
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 <Ch...@setech.com> wrote:
> In the Struts2 Action rather than my service class?
>
>> -----Original Message-----
>> From: Maurizio Cucchiara [mailto:maurizio.cucchiara@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"
>> <Ch...@setech.com>
>> ha scritto:
>> > I still think this is related to my @Transactional annotation maybe.
>> >
>> >> -----Original Message-----
>> >> From: Dave Newton [mailto:davelnewton@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
>> >> <Ch...@setech.com> 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:rouxelec@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" <Ch...@setech.com>
>> >> >> À : Struts Users Mailing List <us...@struts.apache.org>
>> >> >> 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:rouxelec@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"%>
>> >> >> >
>> >> >> > <s:property value="%{logError(exception)}"/>
>> >> >> > <%
>> >> >> > Transaction tx = new
>> >> >> >
>> >> >>
>> >>
>> HibernateUtil().getSessionFactory().getCurrentSession().getTransaction(
>> >> >> > );
>> >> >> > if (tx != null && tx.isActive()) {
>> >> >> > tx.rollback();
>> >> >> > }
>> >> >> > %>
>> >> >> >
>> >> >> > In your struts mapping file :
>> >> >> >
>> >> >> > <global-results>
>> >> >> > <result
>> name="unhandledException">/error.jsp</result>
>> >> >> > </result>
>> >> >> > </global-results>
>> >> >> >
>> >> >> > <global-exception-mappings>
>> >> >> > <exception-mapping exception="java.lang.Exception"
>> >> >> > result="unhandledException" />
>> >> >> > </global-exception-mappings>
>> >> >> >
>> >> >> > hope it will help you
>> >> >> >
>> >> >> >
>> >> >> > ____________________________________________
>> >> >> > ____________________________________________
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > ----- Message d'origine ----
>> >> >> > De : "CRANFORD, CHRIS" <Ch...@setech.com>
>> >> >> > À : Struts Users Mailing List <us...@struts.apache.org>
>> >> >> > Envoyé le : Mer 9 mars 2011, 12h 34min 32s
>> >> >> > Objet : ModelDriven & Hibernate Entities
>> >> >> >
>> >> >> > I had started down a path of using the ModelDriven interface
>> from
>> >> >> > Struts
>> >> >> > because I find it really helps maintain a class action class
>> >> without
>> >> >> > large numbers of get/set methods for screens that contain a lot
>> of
>> >> >> form
>> >> >> > fields.
>> >> >> >
>> >> >> > However, I am finding at least with how I have attempted to
>> >> approach
>> >> >> > ModelDriven to have several drawbacks. For example, by using
>> the
>> >> >> OSIV
>> >> >> > (Open Session In View) filter, I am finding that when Struts
>> sets
>> >> the
>> >> >> > properties on the entity and afterward if an exception is
>> thrown,
>> >> >> > caught
>> >> >> > and handled and doesn't trigger Hibernate to actually
>> "rollback";
>> >> the
>> >> >> > changes are persisted which leaves my entity in a dirty
>> >> inconsistent
>> >> >> > state.
>> >> >> >
>> >> >> > How have others solved this by using your entity domain POJOs
>> in
>> >> your
>> >> >> > view?
>> >> >> >
>> >> >> > Do you use them detached from the session so that you
>> explicitly
>> >> have
>> >> >> > to
>> >> >> > merge them to the session to be persisted? If so, how do you
>> deal
>> >> >> with
>> >> >> > multiple lazy loaded collections in your entity?
>> >> >> >
>> >> >> > Or would using DTO objects from my service layer a better
>> >> alternative
>> >> >> > to
>> >> >> > insure that no data is actually persisted to the database that
>> >> >> > shouldn't
>> >> >> > be?
>> >> >> >
>> >> >> >
>> >> >> > ---------------------------------------------------------------
>> ---
>> >> ---
>> >> >> > 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
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> -----------------------------------------------------------------
>> ---
>> >> -
>> >> >> 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
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------
>> ---
>> >> > 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
>> >>
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > 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
>
>
--
Maurizio Cucchiara
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: Re : Re : ModelDriven & Hibernate Entities
Posted by "CRANFORD, CHRIS" <Ch...@setech.com>.
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.
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="persistenceXmlLocation" value="classpath*:META-INF/persistence.xml" />
<property name="persistenceUnitName" value="pu-mrohub" />
<property name="dataSource" ref="dataSource" />
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
<property name="database" value="SQL_SERVER" />
<property name="showSql" value="false" />
<property name="generateDdl" value="false" />
</bean>
</property>
</bean>
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
<property name="dataSource" ref="dataSource" />
</bean>
<jee:jndi-lookup id="dataSource" jndi-name="jdbc/mssqlserver" resource-ref="true"/>
<tx:annotation-driven transaction-manager="transactionManager" />
<bean id="sessionFactory" factory-bean="entityManagerFactory" factory-method="getSessionFactory" />
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:mgainty@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<String, String> properties = new HashMap<String, String>();
> 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.Cranford@setech.com
> > To: user@struts.apache.org
> >
> > In the Struts2 Action rather than my service class?
> >
> > > -----Original Message-----
> > > From: Maurizio Cucchiara [mailto:maurizio.cucchiara@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"
> > > <Ch...@setech.com>
> > > ha scritto:
> > > > I still think this is related to my @Transactional annotation
> maybe.
> > > >
> > > >> -----Original Message-----
> > > >> From: Dave Newton [mailto:davelnewton@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
> > > >> <Ch...@setech.com> 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:rouxelec@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" <Ch...@setech.com>
> > > >> >> À : Struts Users Mailing List <us...@struts.apache.org>
> > > >> >> 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:rouxelec@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"%>
> > > >> >> >
> > > >> >> > <s:property value="%{logError(exception)}"/>
> > > >> >> > <%
> > > >> >> > Transaction tx = new
> > > >> >> >
> > > >> >>
> > > >>
> > >
> HibernateUtil().getSessionFactory().getCurrentSession().getTransaction(
> > > >> >> > );
> > > >> >> > if (tx != null && tx.isActive()) {
> > > >> >> > tx.rollback();
> > > >> >> > }
> > > >> >> > %>
> > > >> >> >
> > > >> >> > In your struts mapping file :
> > > >> >> >
> > > >> >> > <global-results>
> > > >> >> > <result
> > > name="unhandledException">/error.jsp</result>
> > > >> >> > </result>
> > > >> >> > </global-results>
> > > >> >> >
> > > >> >> > <global-exception-mappings>
> > > >> >> > <exception-mapping
> exception="java.lang.Exception"
> > > >> >> > result="unhandledException" />
> > > >> >> > </global-exception-mappings>
> > > >> >> >
> > > >> >> > hope it will help you
> > > >> >> >
> > > >> >> >
> > > >> >> > ____________________________________________
> > > >> >> > ____________________________________________
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> > ----- Message d'origine ----
> > > >> >> > De : "CRANFORD, CHRIS" <Ch...@setech.com>
> > > >> >> > À : Struts Users Mailing List <us...@struts.apache.org>
> > > >> >> > Envoyé le : Mer 9 mars 2011, 12h 34min 32s
> > > >> >> > Objet : ModelDriven & Hibernate Entities
> > > >> >> >
> > > >> >> > I had started down a path of using the ModelDriven
> interface
> > > from
> > > >> >> > Struts
> > > >> >> > because I find it really helps maintain a class action
> class
> > > >> without
> > > >> >> > large numbers of get/set methods for screens that contain a
> lot
> > > of
> > > >> >> form
> > > >> >> > fields.
> > > >> >> >
> > > >> >> > However, I am finding at least with how I have attempted to
> > > >> approach
> > > >> >> > ModelDriven to have several drawbacks. For example, by
> using
> > > the
> > > >> >> OSIV
> > > >> >> > (Open Session In View) filter, I am finding that when
> Struts
> > > sets
> > > >> the
> > > >> >> > properties on the entity and afterward if an exception is
> > > thrown,
> > > >> >> > caught
> > > >> >> > and handled and doesn't trigger Hibernate to actually
> > > "rollback";
> > > >> the
> > > >> >> > changes are persisted which leaves my entity in a dirty
> > > >> inconsistent
> > > >> >> > state.
> > > >> >> >
> > > >> >> > How have others solved this by using your entity domain
> POJOs
> > > in
> > > >> your
> > > >> >> > view?
> > > >> >> >
> > > >> >> > Do you use them detached from the session so that you
> > > explicitly
> > > >> have
> > > >> >> > to
> > > >> >> > merge them to the session to be persisted? If so, how do
> you
> > > deal
> > > >> >> with
> > > >> >> > multiple lazy loaded collections in your entity?
> > > >> >> >
> > > >> >> > Or would using DTO objects from my service layer a better
> > > >> alternative
> > > >> >> > to
> > > >> >> > insure that no data is actually persisted to the database
> that
> > > >> >> > shouldn't
> > > >> >> > be?
> > > >> >> >
> > > >> >> >
> > > >> >> > -----------------------------------------------------------
> ----
> > > ---
> > > >> ---
> > > >> >> > 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
> > > >> >> >
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> -------------------------------------------------------------
> ----
> > > ---
> > > >> -
> > > >> >> 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
> > > >> >>
> > > >> >
> > > >> >
> > > >> >
> > > >> > --------------------------------------------------------------
> ----
> > > ---
> > > >> > 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
> > > >>
> > > >
> > > >
> > > >
> > > > -----------------------------------------------------------------
> ----
> > > > 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
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: Re : Re : ModelDriven & Hibernate Entities
Posted by Martin Gainty <mg...@hotmail.com>.
osiv filter (should) set flushing to never (now manual) to prevent accidental writes on the session so
Map<String, String> properties = new HashMap<String, String>();
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.Cranford@setech.com
> To: user@struts.apache.org
>
> In the Struts2 Action rather than my service class?
>
> > -----Original Message-----
> > From: Maurizio Cucchiara [mailto:maurizio.cucchiara@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"
> > <Ch...@setech.com>
> > ha scritto:
> > > I still think this is related to my @Transactional annotation maybe.
> > >
> > >> -----Original Message-----
> > >> From: Dave Newton [mailto:davelnewton@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
> > >> <Ch...@setech.com> 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:rouxelec@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" <Ch...@setech.com>
> > >> >> À : Struts Users Mailing List <us...@struts.apache.org>
> > >> >> 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:rouxelec@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"%>
> > >> >> >
> > >> >> > <s:property value="%{logError(exception)}"/>
> > >> >> > <%
> > >> >> > Transaction tx = new
> > >> >> >
> > >> >>
> > >>
> > HibernateUtil().getSessionFactory().getCurrentSession().getTransaction(
> > >> >> > );
> > >> >> > if (tx != null && tx.isActive()) {
> > >> >> > tx.rollback();
> > >> >> > }
> > >> >> > %>
> > >> >> >
> > >> >> > In your struts mapping file :
> > >> >> >
> > >> >> > <global-results>
> > >> >> > <result
> > name="unhandledException">/error.jsp</result>
> > >> >> > </result>
> > >> >> > </global-results>
> > >> >> >
> > >> >> > <global-exception-mappings>
> > >> >> > <exception-mapping exception="java.lang.Exception"
> > >> >> > result="unhandledException" />
> > >> >> > </global-exception-mappings>
> > >> >> >
> > >> >> > hope it will help you
> > >> >> >
> > >> >> >
> > >> >> > ____________________________________________
> > >> >> > ____________________________________________
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > ----- Message d'origine ----
> > >> >> > De : "CRANFORD, CHRIS" <Ch...@setech.com>
> > >> >> > À : Struts Users Mailing List <us...@struts.apache.org>
> > >> >> > Envoyé le : Mer 9 mars 2011, 12h 34min 32s
> > >> >> > Objet : ModelDriven & Hibernate Entities
> > >> >> >
> > >> >> > I had started down a path of using the ModelDriven interface
> > from
> > >> >> > Struts
> > >> >> > because I find it really helps maintain a class action class
> > >> without
> > >> >> > large numbers of get/set methods for screens that contain a lot
> > of
> > >> >> form
> > >> >> > fields.
> > >> >> >
> > >> >> > However, I am finding at least with how I have attempted to
> > >> approach
> > >> >> > ModelDriven to have several drawbacks. For example, by using
> > the
> > >> >> OSIV
> > >> >> > (Open Session In View) filter, I am finding that when Struts
> > sets
> > >> the
> > >> >> > properties on the entity and afterward if an exception is
> > thrown,
> > >> >> > caught
> > >> >> > and handled and doesn't trigger Hibernate to actually
> > "rollback";
> > >> the
> > >> >> > changes are persisted which leaves my entity in a dirty
> > >> inconsistent
> > >> >> > state.
> > >> >> >
> > >> >> > How have others solved this by using your entity domain POJOs
> > in
> > >> your
> > >> >> > view?
> > >> >> >
> > >> >> > Do you use them detached from the session so that you
> > explicitly
> > >> have
> > >> >> > to
> > >> >> > merge them to the session to be persisted? If so, how do you
> > deal
> > >> >> with
> > >> >> > multiple lazy loaded collections in your entity?
> > >> >> >
> > >> >> > Or would using DTO objects from my service layer a better
> > >> alternative
> > >> >> > to
> > >> >> > insure that no data is actually persisted to the database that
> > >> >> > shouldn't
> > >> >> > be?
> > >> >> >
> > >> >> >
> > >> >> > ---------------------------------------------------------------
> > ---
> > >> ---
> > >> >> > 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
> > >> >> >
> > >> >>
> > >> >>
> > >> >>
> > >> >> -----------------------------------------------------------------
> > ---
> > >> -
> > >> >> 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
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> > ------------------------------------------------------------------
> > ---
> > >> > 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
> > >>
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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: RE: Re : Re : ModelDriven & Hibernate Entities
Posted by "CRANFORD, CHRIS" <Ch...@setech.com>.
In the Struts2 Action rather than my service class?
> -----Original Message-----
> From: Maurizio Cucchiara [mailto:maurizio.cucchiara@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"
> <Ch...@setech.com>
> ha scritto:
> > I still think this is related to my @Transactional annotation maybe.
> >
> >> -----Original Message-----
> >> From: Dave Newton [mailto:davelnewton@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
> >> <Ch...@setech.com> 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:rouxelec@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" <Ch...@setech.com>
> >> >> À : Struts Users Mailing List <us...@struts.apache.org>
> >> >> 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:rouxelec@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"%>
> >> >> >
> >> >> > <s:property value="%{logError(exception)}"/>
> >> >> > <%
> >> >> > Transaction tx = new
> >> >> >
> >> >>
> >>
> HibernateUtil().getSessionFactory().getCurrentSession().getTransaction(
> >> >> > );
> >> >> > if (tx != null && tx.isActive()) {
> >> >> > tx.rollback();
> >> >> > }
> >> >> > %>
> >> >> >
> >> >> > In your struts mapping file :
> >> >> >
> >> >> > <global-results>
> >> >> > <result
> name="unhandledException">/error.jsp</result>
> >> >> > </result>
> >> >> > </global-results>
> >> >> >
> >> >> > <global-exception-mappings>
> >> >> > <exception-mapping exception="java.lang.Exception"
> >> >> > result="unhandledException" />
> >> >> > </global-exception-mappings>
> >> >> >
> >> >> > hope it will help you
> >> >> >
> >> >> >
> >> >> > ____________________________________________
> >> >> > ____________________________________________
> >> >> >
> >> >> >
> >> >> >
> >> >> > ----- Message d'origine ----
> >> >> > De : "CRANFORD, CHRIS" <Ch...@setech.com>
> >> >> > À : Struts Users Mailing List <us...@struts.apache.org>
> >> >> > Envoyé le : Mer 9 mars 2011, 12h 34min 32s
> >> >> > Objet : ModelDriven & Hibernate Entities
> >> >> >
> >> >> > I had started down a path of using the ModelDriven interface
> from
> >> >> > Struts
> >> >> > because I find it really helps maintain a class action class
> >> without
> >> >> > large numbers of get/set methods for screens that contain a lot
> of
> >> >> form
> >> >> > fields.
> >> >> >
> >> >> > However, I am finding at least with how I have attempted to
> >> approach
> >> >> > ModelDriven to have several drawbacks. For example, by using
> the
> >> >> OSIV
> >> >> > (Open Session In View) filter, I am finding that when Struts
> sets
> >> the
> >> >> > properties on the entity and afterward if an exception is
> thrown,
> >> >> > caught
> >> >> > and handled and doesn't trigger Hibernate to actually
> "rollback";
> >> the
> >> >> > changes are persisted which leaves my entity in a dirty
> >> inconsistent
> >> >> > state.
> >> >> >
> >> >> > How have others solved this by using your entity domain POJOs
> in
> >> your
> >> >> > view?
> >> >> >
> >> >> > Do you use them detached from the session so that you
> explicitly
> >> have
> >> >> > to
> >> >> > merge them to the session to be persisted? If so, how do you
> deal
> >> >> with
> >> >> > multiple lazy loaded collections in your entity?
> >> >> >
> >> >> > Or would using DTO objects from my service layer a better
> >> alternative
> >> >> > to
> >> >> > insure that no data is actually persisted to the database that
> >> >> > shouldn't
> >> >> > be?
> >> >> >
> >> >> >
> >> >> > ---------------------------------------------------------------
> ---
> >> ---
> >> >> > 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
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> -----------------------------------------------------------------
> ---
> >> -
> >> >> 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
> >> >>
> >> >
> >> >
> >> >
> >> > ------------------------------------------------------------------
> ---
> >> > 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
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: RE: Re : Re : ModelDriven & Hibernate Entities
Posted by Maurizio Cucchiara <ma...@gmail.com>.
Have you tried to put the transational annotation in the class declaration?
Maurizio Cucchiara
Il giorno 09/mar/2011 21.38, "CRANFORD, CHRIS" <Ch...@setech.com>
ha scritto:
> I still think this is related to my @Transactional annotation maybe.
>
>> -----Original Message-----
>> From: Dave Newton [mailto:davelnewton@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
>> <Ch...@setech.com> 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:rouxelec@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" <Ch...@setech.com>
>> >> À : Struts Users Mailing List <us...@struts.apache.org>
>> >> 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:rouxelec@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"%>
>> >> >
>> >> > <s:property value="%{logError(exception)}"/>
>> >> > <%
>> >> > Transaction tx = new
>> >> >
>> >>
>> HibernateUtil().getSessionFactory().getCurrentSession().getTransaction(
>> >> > );
>> >> > if (tx != null && tx.isActive()) {
>> >> > tx.rollback();
>> >> > }
>> >> > %>
>> >> >
>> >> > In your struts mapping file :
>> >> >
>> >> > <global-results>
>> >> > <result name="unhandledException">/error.jsp</result>
>> >> > </result>
>> >> > </global-results>
>> >> >
>> >> > <global-exception-mappings>
>> >> > <exception-mapping exception="java.lang.Exception"
>> >> > result="unhandledException" />
>> >> > </global-exception-mappings>
>> >> >
>> >> > hope it will help you
>> >> >
>> >> >
>> >> > ____________________________________________
>> >> > ____________________________________________
>> >> >
>> >> >
>> >> >
>> >> > ----- Message d'origine ----
>> >> > De : "CRANFORD, CHRIS" <Ch...@setech.com>
>> >> > À : Struts Users Mailing List <us...@struts.apache.org>
>> >> > Envoyé le : Mer 9 mars 2011, 12h 34min 32s
>> >> > Objet : ModelDriven & Hibernate Entities
>> >> >
>> >> > I had started down a path of using the ModelDriven interface from
>> >> > Struts
>> >> > because I find it really helps maintain a class action class
>> without
>> >> > large numbers of get/set methods for screens that contain a lot of
>> >> form
>> >> > fields.
>> >> >
>> >> > However, I am finding at least with how I have attempted to
>> approach
>> >> > ModelDriven to have several drawbacks. For example, by using the
>> >> OSIV
>> >> > (Open Session In View) filter, I am finding that when Struts sets
>> the
>> >> > properties on the entity and afterward if an exception is thrown,
>> >> > caught
>> >> > and handled and doesn't trigger Hibernate to actually "rollback";
>> the
>> >> > changes are persisted which leaves my entity in a dirty
>> inconsistent
>> >> > state.
>> >> >
>> >> > How have others solved this by using your entity domain POJOs in
>> your
>> >> > view?
>> >> >
>> >> > Do you use them detached from the session so that you explicitly
>> have
>> >> > to
>> >> > merge them to the session to be persisted? If so, how do you deal
>> >> with
>> >> > multiple lazy loaded collections in your entity?
>> >> >
>> >> > Or would using DTO objects from my service layer a better
>> alternative
>> >> > to
>> >> > insure that no data is actually persisted to the database that
>> >> > shouldn't
>> >> > be?
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------
>> ---
>> >> > 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
>> >> >
>> >>
>> >>
>> >>
>> >> --------------------------------------------------------------------
>> -
>> >> 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
>> >>
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
RE: Re : Re : ModelDriven & Hibernate Entities
Posted by "CRANFORD, CHRIS" <Ch...@setech.com>.
I still think this is related to my @Transactional annotation maybe.
> -----Original Message-----
> From: Dave Newton [mailto:davelnewton@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
> <Ch...@setech.com> 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:rouxelec@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" <Ch...@setech.com>
> >> À : Struts Users Mailing List <us...@struts.apache.org>
> >> 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:rouxelec@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"%>
> >> >
> >> > <s:property value="%{logError(exception)}"/>
> >> > <%
> >> > Transaction tx = new
> >> >
> >>
> HibernateUtil().getSessionFactory().getCurrentSession().getTransaction(
> >> > );
> >> > if (tx != null && tx.isActive()) {
> >> > tx.rollback();
> >> > }
> >> > %>
> >> >
> >> > In your struts mapping file :
> >> >
> >> > <global-results>
> >> > <result name="unhandledException">/error.jsp</result>
> >> > </result>
> >> > </global-results>
> >> >
> >> > <global-exception-mappings>
> >> > <exception-mapping exception="java.lang.Exception"
> >> > result="unhandledException" />
> >> > </global-exception-mappings>
> >> >
> >> > hope it will help you
> >> >
> >> >
> >> > ____________________________________________
> >> > ____________________________________________
> >> >
> >> >
> >> >
> >> > ----- Message d'origine ----
> >> > De : "CRANFORD, CHRIS" <Ch...@setech.com>
> >> > À : Struts Users Mailing List <us...@struts.apache.org>
> >> > Envoyé le : Mer 9 mars 2011, 12h 34min 32s
> >> > Objet : ModelDriven & Hibernate Entities
> >> >
> >> > I had started down a path of using the ModelDriven interface from
> >> > Struts
> >> > because I find it really helps maintain a class action class
> without
> >> > large numbers of get/set methods for screens that contain a lot of
> >> form
> >> > fields.
> >> >
> >> > However, I am finding at least with how I have attempted to
> approach
> >> > ModelDriven to have several drawbacks. For example, by using the
> >> OSIV
> >> > (Open Session In View) filter, I am finding that when Struts sets
> the
> >> > properties on the entity and afterward if an exception is thrown,
> >> > caught
> >> > and handled and doesn't trigger Hibernate to actually "rollback";
> the
> >> > changes are persisted which leaves my entity in a dirty
> inconsistent
> >> > state.
> >> >
> >> > How have others solved this by using your entity domain POJOs in
> your
> >> > view?
> >> >
> >> > Do you use them detached from the session so that you explicitly
> have
> >> > to
> >> > merge them to the session to be persisted? If so, how do you deal
> >> with
> >> > multiple lazy loaded collections in your entity?
> >> >
> >> > Or would using DTO objects from my service layer a better
> alternative
> >> > to
> >> > insure that no data is actually persisted to the database that
> >> > shouldn't
> >> > be?
> >> >
> >> >
> >> > ------------------------------------------------------------------
> ---
> >> > 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
> >> >
> >>
> >>
> >>
> >> --------------------------------------------------------------------
> -
> >> 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
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Re : Re : ModelDriven & Hibernate Entities
Posted by Dave Newton <da...@gmail.com>.
Another reason OSiV filters can be tricky.
Dave
On Wed, Mar 9, 2011 at 2:04 PM, CRANFORD, CHRIS
<Ch...@setech.com> 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:rouxelec@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" <Ch...@setech.com>
>> À : Struts Users Mailing List <us...@struts.apache.org>
>> 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:rouxelec@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"%>
>> >
>> > <s:property value="%{logError(exception)}"/>
>> > <%
>> > Transaction tx = new
>> >
>> HibernateUtil().getSessionFactory().getCurrentSession().getTransaction(
>> > );
>> > if (tx != null && tx.isActive()) {
>> > tx.rollback();
>> > }
>> > %>
>> >
>> > In your struts mapping file :
>> >
>> > <global-results>
>> > <result name="unhandledException">/error.jsp</result>
>> > </result>
>> > </global-results>
>> >
>> > <global-exception-mappings>
>> > <exception-mapping exception="java.lang.Exception"
>> > result="unhandledException" />
>> > </global-exception-mappings>
>> >
>> > hope it will help you
>> >
>> >
>> > ____________________________________________
>> > ____________________________________________
>> >
>> >
>> >
>> > ----- Message d'origine ----
>> > De : "CRANFORD, CHRIS" <Ch...@setech.com>
>> > À : Struts Users Mailing List <us...@struts.apache.org>
>> > Envoyé le : Mer 9 mars 2011, 12h 34min 32s
>> > Objet : ModelDriven & Hibernate Entities
>> >
>> > I had started down a path of using the ModelDriven interface from
>> > Struts
>> > because I find it really helps maintain a class action class without
>> > large numbers of get/set methods for screens that contain a lot of
>> form
>> > fields.
>> >
>> > However, I am finding at least with how I have attempted to approach
>> > ModelDriven to have several drawbacks. For example, by using the
>> OSIV
>> > (Open Session In View) filter, I am finding that when Struts sets the
>> > properties on the entity and afterward if an exception is thrown,
>> > caught
>> > and handled and doesn't trigger Hibernate to actually "rollback"; the
>> > changes are persisted which leaves my entity in a dirty inconsistent
>> > state.
>> >
>> > How have others solved this by using your entity domain POJOs in your
>> > view?
>> >
>> > Do you use them detached from the session so that you explicitly have
>> > to
>> > merge them to the session to be persisted? If so, how do you deal
>> with
>> > multiple lazy loaded collections in your entity?
>> >
>> > Or would using DTO objects from my service layer a better alternative
>> > to
>> > insure that no data is actually persisted to the database that
>> > shouldn't
>> > be?
>> >
>> >
>> > ---------------------------------------------------------------------
>> > 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
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>
>
>
> ---------------------------------------------------------------------
> 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: Re : Re : ModelDriven & Hibernate Entities
Posted by "CRANFORD, CHRIS" <Ch...@setech.com>.
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:thechrispratt@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
> <Ch...@setech.com>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:rouxelec@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" <Ch...@setech.com>
> > > À : Struts Users Mailing List <us...@struts.apache.org>
> > > 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:rouxelec@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"%>
> > > >
> > > > <s:property value="%{logError(exception)}"/>
> > > > <%
> > > > Transaction tx = new
> > > >
> > >
> HibernateUtil().getSessionFactory().getCurrentSession().getTransaction(
> > > > );
> > > > if (tx != null && tx.isActive()) {
> > > > tx.rollback();
> > > > }
> > > > %>
> > > >
> > > > In your struts mapping file :
> > > >
> > > > <global-results>
> > > > <result name="unhandledException">/error.jsp</result>
> > > > </result>
> > > > </global-results>
> > > >
> > > > <global-exception-mappings>
> > > > <exception-mapping exception="java.lang.Exception"
> > > > result="unhandledException" />
> > > > </global-exception-mappings>
> > > >
> > > > hope it will help you
> > > >
> > > >
> > > > ____________________________________________
> > > > ____________________________________________
> > > >
> > > >
> > > >
> > > > ----- Message d'origine ----
> > > > De : "CRANFORD, CHRIS" <Ch...@setech.com>
> > > > À : Struts Users Mailing List <us...@struts.apache.org>
> > > > Envoyé le : Mer 9 mars 2011, 12h 34min 32s
> > > > Objet : ModelDriven & Hibernate Entities
> > > >
> > > > I had started down a path of using the ModelDriven interface from
> > > > Struts
> > > > because I find it really helps maintain a class action class
> without
> > > > large numbers of get/set methods for screens that contain a lot
> of
> > > form
> > > > fields.
> > > >
> > > > However, I am finding at least with how I have attempted to
> approach
> > > > ModelDriven to have several drawbacks. For example, by using the
> > > OSIV
> > > > (Open Session In View) filter, I am finding that when Struts sets
> the
> > > > properties on the entity and afterward if an exception is thrown,
> > > > caught
> > > > and handled and doesn't trigger Hibernate to actually "rollback";
> the
> > > > changes are persisted which leaves my entity in a dirty
> inconsistent
> > > > state.
> > > >
> > > > How have others solved this by using your entity domain POJOs in
> your
> > > > view?
> > > >
> > > > Do you use them detached from the session so that you explicitly
> have
> > > > to
> > > > merge them to the session to be persisted? If so, how do you
> deal
> > > with
> > > > multiple lazy loaded collections in your entity?
> > > >
> > > > Or would using DTO objects from my service layer a better
> alternative
> > > > to
> > > > insure that no data is actually persisted to the database that
> > > > shouldn't
> > > > be?
> > > >
> > > >
> > > > -----------------------------------------------------------------
> ----
> > > > 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
> > > >
> > >
> > >
> > >
> > > -------------------------------------------------------------------
> --
> > > 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
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: Re : Re : ModelDriven & Hibernate Entities
Posted by Chris Pratt <th...@gmail.com>.
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
<Ch...@setech.com>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:rouxelec@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" <Ch...@setech.com>
> > À : Struts Users Mailing List <us...@struts.apache.org>
> > 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:rouxelec@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"%>
> > >
> > > <s:property value="%{logError(exception)}"/>
> > > <%
> > > Transaction tx = new
> > >
> > HibernateUtil().getSessionFactory().getCurrentSession().getTransaction(
> > > );
> > > if (tx != null && tx.isActive()) {
> > > tx.rollback();
> > > }
> > > %>
> > >
> > > In your struts mapping file :
> > >
> > > <global-results>
> > > <result name="unhandledException">/error.jsp</result>
> > > </result>
> > > </global-results>
> > >
> > > <global-exception-mappings>
> > > <exception-mapping exception="java.lang.Exception"
> > > result="unhandledException" />
> > > </global-exception-mappings>
> > >
> > > hope it will help you
> > >
> > >
> > > ____________________________________________
> > > ____________________________________________
> > >
> > >
> > >
> > > ----- Message d'origine ----
> > > De : "CRANFORD, CHRIS" <Ch...@setech.com>
> > > À : Struts Users Mailing List <us...@struts.apache.org>
> > > Envoyé le : Mer 9 mars 2011, 12h 34min 32s
> > > Objet : ModelDriven & Hibernate Entities
> > >
> > > I had started down a path of using the ModelDriven interface from
> > > Struts
> > > because I find it really helps maintain a class action class without
> > > large numbers of get/set methods for screens that contain a lot of
> > form
> > > fields.
> > >
> > > However, I am finding at least with how I have attempted to approach
> > > ModelDriven to have several drawbacks. For example, by using the
> > OSIV
> > > (Open Session In View) filter, I am finding that when Struts sets the
> > > properties on the entity and afterward if an exception is thrown,
> > > caught
> > > and handled and doesn't trigger Hibernate to actually "rollback"; the
> > > changes are persisted which leaves my entity in a dirty inconsistent
> > > state.
> > >
> > > How have others solved this by using your entity domain POJOs in your
> > > view?
> > >
> > > Do you use them detached from the session so that you explicitly have
> > > to
> > > merge them to the session to be persisted? If so, how do you deal
> > with
> > > multiple lazy loaded collections in your entity?
> > >
> > > Or would using DTO objects from my service layer a better alternative
> > > to
> > > insure that no data is actually persisted to the database that
> > > shouldn't
> > > be?
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
RE: Re : Re : ModelDriven & Hibernate Entities
Posted by "CRANFORD, CHRIS" <Ch...@setech.com>.
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:rouxelec@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" <Ch...@setech.com>
> À : Struts Users Mailing List <us...@struts.apache.org>
> 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:rouxelec@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"%>
> >
> > <s:property value="%{logError(exception)}"/>
> > <%
> > Transaction tx = new
> >
> HibernateUtil().getSessionFactory().getCurrentSession().getTransaction(
> > );
> > if (tx != null && tx.isActive()) {
> > tx.rollback();
> > }
> > %>
> >
> > In your struts mapping file :
> >
> > <global-results>
> > <result name="unhandledException">/error.jsp</result>
> > </result>
> > </global-results>
> >
> > <global-exception-mappings>
> > <exception-mapping exception="java.lang.Exception"
> > result="unhandledException" />
> > </global-exception-mappings>
> >
> > hope it will help you
> >
> >
> > ____________________________________________
> > ____________________________________________
> >
> >
> >
> > ----- Message d'origine ----
> > De : "CRANFORD, CHRIS" <Ch...@setech.com>
> > À : Struts Users Mailing List <us...@struts.apache.org>
> > Envoyé le : Mer 9 mars 2011, 12h 34min 32s
> > Objet : ModelDriven & Hibernate Entities
> >
> > I had started down a path of using the ModelDriven interface from
> > Struts
> > because I find it really helps maintain a class action class without
> > large numbers of get/set methods for screens that contain a lot of
> form
> > fields.
> >
> > However, I am finding at least with how I have attempted to approach
> > ModelDriven to have several drawbacks. For example, by using the
> OSIV
> > (Open Session In View) filter, I am finding that when Struts sets the
> > properties on the entity and afterward if an exception is thrown,
> > caught
> > and handled and doesn't trigger Hibernate to actually "rollback"; the
> > changes are persisted which leaves my entity in a dirty inconsistent
> > state.
> >
> > How have others solved this by using your entity domain POJOs in your
> > view?
> >
> > Do you use them detached from the session so that you explicitly have
> > to
> > merge them to the session to be persisted? If so, how do you deal
> with
> > multiple lazy loaded collections in your entity?
> >
> > Or would using DTO objects from my service layer a better alternative
> > to
> > insure that no data is actually persisted to the database that
> > shouldn't
> > be?
> >
> >
> > ---------------------------------------------------------------------
> > 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
> >
>
>
>
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re : Re : ModelDriven & Hibernate Entities
Posted by François Rouxel <ro...@yahoo.com>.
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" <Ch...@setech.com>
À : Struts Users Mailing List <us...@struts.apache.org>
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:rouxelec@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"%>
>
> <s:property value="%{logError(exception)}"/>
> <%
> Transaction tx = new
> HibernateUtil().getSessionFactory().getCurrentSession().getTransaction(
> );
> if (tx != null && tx.isActive()) {
> tx.rollback();
> }
> %>
>
> In your struts mapping file :
>
> <global-results>
> <result name="unhandledException">/error.jsp</result>
> </result>
> </global-results>
>
> <global-exception-mappings>
> <exception-mapping exception="java.lang.Exception"
> result="unhandledException" />
> </global-exception-mappings>
>
> hope it will help you
>
>
> ____________________________________________
> ____________________________________________
>
>
>
> ----- Message d'origine ----
> De : "CRANFORD, CHRIS" <Ch...@setech.com>
> À : Struts Users Mailing List <us...@struts.apache.org>
> Envoyé le : Mer 9 mars 2011, 12h 34min 32s
> Objet : ModelDriven & Hibernate Entities
>
> I had started down a path of using the ModelDriven interface from
> Struts
> because I find it really helps maintain a class action class without
> large numbers of get/set methods for screens that contain a lot of form
> fields.
>
> However, I am finding at least with how I have attempted to approach
> ModelDriven to have several drawbacks. For example, by using the OSIV
> (Open Session In View) filter, I am finding that when Struts sets the
> properties on the entity and afterward if an exception is thrown,
> caught
> and handled and doesn't trigger Hibernate to actually "rollback"; the
> changes are persisted which leaves my entity in a dirty inconsistent
> state.
>
> How have others solved this by using your entity domain POJOs in your
> view?
>
> Do you use them detached from the session so that you explicitly have
> to
> merge them to the session to be persisted? If so, how do you deal with
> multiple lazy loaded collections in your entity?
>
> Or would using DTO objects from my service layer a better alternative
> to
> insure that no data is actually persisted to the database that
> shouldn't
> be?
>
>
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
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: Re : ModelDriven & Hibernate Entities
Posted by "CRANFORD, CHRIS" <Ch...@setech.com>.
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:rouxelec@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"%>
>
> <s:property value="%{logError(exception)}"/>
> <%
> Transaction tx = new
> HibernateUtil().getSessionFactory().getCurrentSession().getTransaction(
> );
> if (tx != null && tx.isActive()) {
> tx.rollback();
> }
> %>
>
> In your struts mapping file :
>
> <global-results>
> <result name="unhandledException">/error.jsp</result>
> </result>
> </global-results>
>
> <global-exception-mappings>
> <exception-mapping exception="java.lang.Exception"
> result="unhandledException" />
> </global-exception-mappings>
>
> hope it will help you
>
>
> ____________________________________________
> ____________________________________________
>
>
>
> ----- Message d'origine ----
> De : "CRANFORD, CHRIS" <Ch...@setech.com>
> À : Struts Users Mailing List <us...@struts.apache.org>
> Envoyé le : Mer 9 mars 2011, 12h 34min 32s
> Objet : ModelDriven & Hibernate Entities
>
> I had started down a path of using the ModelDriven interface from
> Struts
> because I find it really helps maintain a class action class without
> large numbers of get/set methods for screens that contain a lot of form
> fields.
>
> However, I am finding at least with how I have attempted to approach
> ModelDriven to have several drawbacks. For example, by using the OSIV
> (Open Session In View) filter, I am finding that when Struts sets the
> properties on the entity and afterward if an exception is thrown,
> caught
> and handled and doesn't trigger Hibernate to actually "rollback"; the
> changes are persisted which leaves my entity in a dirty inconsistent
> state.
>
> How have others solved this by using your entity domain POJOs in your
> view?
>
> Do you use them detached from the session so that you explicitly have
> to
> merge them to the session to be persisted? If so, how do you deal with
> multiple lazy loaded collections in your entity?
>
> Or would using DTO objects from my service layer a better alternative
> to
> insure that no data is actually persisted to the database that
> shouldn't
> be?
>
>
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org