Gary,
Thanks a lot for bringing this to my attention. You are correct, that's
the setup I have in place. I checked my "readonly" configuration and it
turned out that there was a hidden bug in my xml code (nasty to trace)
where the "read-only" attribute was not part part of my "get*" keys. I
c
This post is going to make a few assumptions:
1) You're using S2 and Spring
2) You're using Spring's OSIV filter (as opposed to Hibernate's)
3) You're using Spring's Hibernate DAO framework
4) You're using a Spring-configured transaction manager
5) You're declaring transaction boundaries and thei
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 transacti
There's a brief page with some links regarding Hibernate integration
*
http://struts.apache.org/2.x/docs/does-the-framework-integrate-with-hibernate.html
which may have been it.
-Ted.
On Dec 18, 2007 6:43 AM, Jeromy Evans <[EMAIL PROTECTED]> wrote:
>
> Ted Husted wrote:
> > On Dec 17, 2007 4:
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), bu
Ted Husted wrote:
On Dec 17, 2007 4:24 PM, Jeromy Evans <[EMAIL PROTECTED]> wrote:
Personally I think writing to attached entities from the view is a bad
idea precisely due to this issue (and exception handling, and others),
even though it's recommended practice on the struts2 wiki.
Wh
On Dec 17, 2007 4:24 PM, Jeromy Evans <[EMAIL PROTECTED]> wrote:
> Personally I think writing to attached entities from the view is a bad
> idea precisely due to this issue (and exception handling, and others),
> even though it's recommended practice on the struts2 wiki.
Where?
-T.
-
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 be
I used an interesting architecture recently where the model was the only layer
allowed to edit the POJOs. The model passed out objects showing only an
interface with getters on. The MVC layer couldn't change anything if it wanted
to. This was a security issue, because the model layer inherently
That's correct - if you make an entity dirty while it's attached to a
session the changes will be committed when the session is flushed.
You've made an attached object dirty, so you either have to detach it
when validation fails or force hibernate not to commit it (don't allow
it to flush). P
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) bu
11 matches
Mail list logo
