There's a wiki page with some examples of accessing Hibernate (or JPA) from an Action or an Interceptor.
* http://struts.apache.org/2.x/docs/does-the-framework-integrate-with-hibernate.html The interceptor case could be improved in a couple of ways. One way might be to only handle the transaction if the Action implements an "PersistenceAware" interface. The PersistenceAware interface might include a boolean property that the Action could set if the transaction should be rolled back. -- HTH, Ted * <http://www.StrutsMentor.com/> On Dec 18, 2007 2:04 PM, Alberto A. Flores <[EMAIL PROTECTED]> wrote: > Thank you everyone for all your input. > > I'm currently opting for changing my code (luckily is not that much) to > never maintained a "persistent" object within the ValueStack, but rather > a "transient" object. Of course, this is an additional overhead (have to > copy the object, query, etc, etc), but I think is our best approach > since Hibernate Validator is not viable option right now (I would also > argue that validation could/should be pushed back to the model, > unfortunately we are working with a poorly design db where we use > reverse engineering to build all hbm and src files and I'm not sure if I > have enough resources to fix that part of our build, e.g. add Hibernate > Validator, modify templates, etc). > > If I may ask, how to "avoid the transaction commit when validation > fails" (as you mentioned)? Is there an interceptor to handle this > scenario? I see that the workflow interceptor is part of the xwork > package (not available with Struts2 distribution source code) and before > I jump into repackaging one from xwork source (which I'm not even sure > where can I find one), I would probably consider writing one myself to > handle this case. I also notice that the validate() method is triggered > before the prepare() method (which makes total sense), however I would > like to guess that this scenario is best handled by an "interceptor" as > I sensed such is the recommended approach in the documentation. > > > > Ted Husted wrote: > > When a workflow automatically opens and closes a transaction, so that > > it can cover multiple operations, and something goes wrong during the > > course of the transaction, then we need to rollback the transaction. > > > > In the case of validation, sometimes changes are made to a property > > which causes it to become (for example) NULL, and later in the > > lifecycle the validator sees that the property is NULL, and raises the > > validation error. But, by then, the property is changed, and the > > Hibernate Session (or JPA EntityManager) will commit the change when > > the transaction is automatically closed. > > > > Since the Hibernate Validator and JSR 299 push validation back to the > > model (where it arguably belongs), making it easy to signal for a > > rollback in a multioperation transaction becomes more important. > > > > I'm still ramping up on the JPA myself, but in some early tests I > > found that not committing the transaction has the same affect of a > > rollback. > > > > -- HTH, Ted > > * <http://www.StrutsMentor.com/> > > > > On Dec 17, 2007 4:04 PM, Alberto A. Flores <[EMAIL PROTECTED]> wrote: > >> Is anyone using openSessionInView with Struts 2 (Hibernate, Spring)? > >> > >> I've found a problem where a domain model is still persisted (even > >> though I'm not saving it) after validation finishes (showing validation > >> errors). My prepare method makes a query (using a > >> HibernateTemplate().get() method) but that's all? Has anyone seen > >> something similar? > >> > >> I'm very sorry if this is not a Struts2 question, but thought of asking > >> since Struts2 is using Filters now and was wondering if anyone has seen > >> any similar behavior. > >> > >> Thanks, > >> > >> -- > >> > >> Alberto A. Flores > >> http://www.linkedin.com/in/aflores --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
