struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Pratt <thechrispr...@gmail.com>
Subject Re: Re : Re : ModelDriven & Hibernate Entities
Date Wed, 09 Mar 2011 19:35:24 GMT
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
<Chris.Cranford@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" <Chris.Cranford@setech.com>
> > À : Struts Users Mailing List <user@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" <Chris.Cranford@setech.com>
> > > À : Struts Users Mailing List <user@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message