Thanks for your answer, i learned a bit more of tapestry.

Now i have one more problem, not exactly related but in the same area.

I have

        void onValidateForm() {
                if (entity.getId().longValue() == 0l) {
                        league.setId(null);
                }

                System.out.println("OnValidateForm");
                try {
                _entityDAO.persist(entity);
                } catch (RuntimeException ex) {
                        leagueForm.recordError("error"); // EXCEPTION IS THROWN 
- THE TEST
I'M DOING HITS THE UNIQUE CONSTRAINT
                }

        }

        void onFailure() {
                _entityDAO.abort();
                System.out.println("onFailure");
        }

And this is working except it doesn't refresh the form with the errors
i added on the onValidate

When i use:

        Object onFailure() {
                _entityDAO.abort();
                System.out.println("onFailure");
                return this;
        }

The following exception is thrown:

Caused by: org.apache.tapestry5.ioc.internal.util.TapestryException:
null id in pt.hi.asianconnect.entities.League entry (don't flush the
Session after an exception occurs) [at
classpath:pt/hi/asianconnect/components/generated/CreateUpdateLeague.tml,
line 12]
        at 
org.apache.tapestry5.internal.bindings.PropBinding.get(PropBinding.java:62)
        at 
org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl$1.read(InternalComponentResourcesImpl.java:510)
        ... 119 more
Caused by: org.hibernate.AssertionFailure: null id in
pt.hi.asianconnect.entities.League entry (don't flush the Session
after an exception occurs)
        at 
org.hibernate.event.def.DefaultFlushEntityEventListener.checkId(DefaultFlushEntityEventListener.java:78)
        at 
org.hibernate.event.def.DefaultFlushEntityEventListener.getValues(DefaultFlushEntityEventListener.java:187)
        at 
org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:143)
        at 
org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:219)
        at 
org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:99)
        at 
org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:58)
        at 
org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:996)
        at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1589)
        at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306)
        at DefaultHibernateDAO.findByCriteria(DefaultHibernateDAO.java:104)


The abort method from DAO was an experiment of mine wich calls
hibernatesessionmanager.abort(). From what i understand, what happens
is when the page is to be renderered, the hibernatesessionmanager
that's used has "dirty" data that's why it uses
SessionImpl.autoFlushIfRequired when i'm fetching data to refill the
page, hence my experiment on calling the abort from
hibernatesessionmanger, still this doesn't do it and i don't know how
to "clean" data from the sessionmanager.

Ideas anyone?

One importante note, the test i'm doing implies that the my method
that saveOrUpdate the entity is "hitting" a unique constraint

On Thu, Sep 10, 2009 at 11:20 PM, Kalle Korhonen
<kalle.o.korho...@gmail.com> wrote:
> You should instead try storing it onValidate. If it fails, you should
> record an error and if it succeeds you should commit only in onSuccess
> (but the method body can be otherwise empty).
>
> Kalle
>
>
> On Thu, Sep 10, 2009 at 2:55 PM, Bruno Santos <bitbet...@gmail.com> wrote:
>> Good evening,
>>
>> I have a form using a zone and i have @CommitAfter on the
>> onSubmitFromEntityForm()
>>
>> <t:form t:id="entityForm" zone="entityZone">
>> <input type="text" t:type="textfield" t:id="name"
>>                                        t:value="entity.name" />
>> </t:form>
>>
>> @CommitAfter
>> Object onSubmitFromEntityForm() {
>>  ....
>> try {
>> entityDao.persist(entity);
>> } catch (exception ex) {
>>  // handle exception
>> }
>> }
>>
>> altough i'm handling the exception the @CommitAfter creates a new
>> exception since it tries to commit something that's not in transaction
>> due to catched exception.
>>
>> How to deal with this? Is there a way to avoid the @CommitAfter to
>> execute ... a handler i can use? I think i can remove the @CommitAfter
>> but don't believe this should be first option.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to