Yes. But I am using Spring managed transactions that in my understanding
are outside of the struts Interceptor stack.
My DAO's are annotated with the
org.springframework.transaction.annotation.Transactional annotation and
thus have their transactions managed as detailed here:
http://static.sp
OK: I've fixed the problem.
I'm not sure why this was the case, but here is what was causing the
problem:
In my ModelDriven action, I had a method like this:
public Collection getAllProjectTypes(){
return this.projectTypeDao.getAll();
}
Notice that instead of returning a simple
Yes. It is my understanding the that Hibernate FlushMode MANUAL or NEVER
(deprecated) instructs Hibernate to only flush the session when explitly
instructed to do so. In my case, I assume this means on a call to
EntityManager.flush().
By default, the mode seems to be set to AUTO. I've tried un
Unfortunately, it appears that xworks validation works not on the
ServletRequest parameters, but on the properties already set on the Action
- or in my case the model bean. So moving the interceptor up the stack
would just break validation.
>From the com.opensymphony.xwork2.validator.Validatio
Yes, musachy. I do something very similar. Here is my prepare() method:
public void prepare() throws Exception {
if( this.id==0 ) {
this.entity = new Entity();
} else {
this.entity = this.entityDao.findById(this.id);
}
}
Here is the (obvious
Thanks Piero:
* don't flush the session and destroy the object
This is exactly what I want to do. However, the Hibernate session
automatically flushes when the EntityManager is closed during the
OpenEntityManagerInView filter exit filter operation. I definitely need
the filter in place to lazy
That's an interesting idea Dave. I'm using the paramsPrepareStack. It'll
take some investigation to see if that would fix the issue.
best,
Jon French
Programmer
ASRC Management Services
ECOS Development Team
[EMAIL PROTECTED]
970-226-9290
Fort Collins Science Center
US Geological Survey
2150 Ce
True. The action's "execute" method is not being called. However, in the
ModelDriven pattern, the invalid (in my case Null) request parameters are
set on the Model during request processing. This is opposed to a
non-ModelDriven action where the parameters would be set on Action
properties.
Sin
I have a ModelDriven action which controls CRUD operations on JPA managed
Entity E. E has a property called ?name? which maps to a database column
with a NOT NULL constraint. I have added a RequiredStringValidator
annotation to my Action to validate that the ?model.name? property is
non-null. T
9 matches
Mail list logo
