On Wed, 21 Aug 2013 10:47:35 -0300, nn kk wrote:
Hi,
Hi!
I want to create my custom exception handling, I saw there are a few
ways to replace the Exception Report Page or override the
RequestExceptionHandler and again replace the default page. But is it
possible to handle only specifi
Take a look at Tynamo tapestry-exceptionpage module.
http://docs.codehaus.org/display/TYNAMO/tapestry-exceptionpage+guide
On Aug 21, 2013, at 9:47 AM, nn kk wrote:
> Hi,
> I want to create my custom exception handling, I saw there are a few ways to
> replace the Exception Report Page or override
Good thing, that's one way to set things up and I've used it myself
but it only goes half way. The even better idea (if I say so myself)
is to use Tynamo's (and in the future core Tapestry)
tapestry-exceptionpage module for mapping exceptions directly to error
pages (see http://tynamo.org/tapestry-
Hi Kalle,
yes I managed finally track down the answer after searching through
pages of search results, unfortunately my original search query
included the terms "tomcat", "tapestry" and "error" which produces
reams of result (most of them irrelevant)!
Like you mentioned in your reply I needed to
Are you setting an error code to your response? You haven't configured
the filter to handle error dispatches:
app
/*
REQUEST
ERROR
Error handling in Jetty and Tomcat differ, see
http://www.cacoethes.co.uk/blog/softwa
/email.html for important
additional terms relating to this e-mail.
- Original Message -
From: "Thiago H. de Paula Figueiredo"
To: "Tapestry users"
Sent: Monday, 8 March, 2010 15:21:45 GMT +02:00 Athens, Beirut, Bucharest,
Istanbul
Subject: Re: Exception handling
On Mo
On Mon, 08 Mar 2010 05:40:50 -0300, Peter Stavrinides
wrote:
Hi everyone,
Hi!
So my question is what approach can I take to intercept *only these
exceptions that don't make it to the page.
Create your own error page. It must implement the ExceptionReporter
interface. Set the tapestry
Agreed. Any number of exceptions can occur when you commit, regardless
of what queries you've run in the same transaction. That's the nature
of multi-user systems, unless of course you want to set the
transaction isolation level to serialize (not usually recommended).
As for using onValida
2009/9/12 Thiago H. de Paula Figueiredo :
> Em Sat, 12 Sep 2009 17:38:43 -0300, Bruno Santos
> escreveu:
>
>> Well, even if i do:
>>
>> league = new League();
>> league.setName("repeated name");
>
> Unique constraints like this should be checked by you *before* sending an
> insert or update to the
Em Sat, 12 Sep 2009 17:38:43 -0300, Bruno Santos
escreveu:
Well, even if i do:
league = new League();
league.setName("repeated name");
Unique constraints like this should be checked by you *before* sending an
insert or update to the database.
--
Thiago H. de Paula Figueiredo
Independen
Well, even if i do:
league = new League();
league.setName("repeated name");
I still have same problem, even without that piece of code.
Everything works fine with Create/Update of entity if saveorupdate
doesn't violate any constraint.
On Sat, Sep 12, 2009 at 7:34 PM, Kalle Korhonen
wrote:
> Y
Yes, but the problem originates from this:
if (entity.getId().longValue() == 0l) {
league.setId(null);
}
You can't make that league object a new entity just by nullifying it's
id. Try creating a new league if you need to. Later on, since the
save
The question is i'm not trying to flush anything, i do (through DAO)
session.saveOrUpdate, catch the exception and the only thing i do
besides registering the error on the form is returning this (the page
i'm at) wich causes (i guess) tapestry to query database to fill data
for selectmodels. And, a
On Fri, Sep 11, 2009 at 7:26 PM, Thiago H. de Paula Figueiredo
wrote:
> Em Fri, 11 Sep 2009 23:11:59 -0300, Kalle Korhonen
> escreveu:
> I think onValidate() is for validation, the data store should only be
> changed (or attepted to be changed) when validation succeeds and controller
> classes (b
Em Fri, 11 Sep 2009 23:11:59 -0300, Kalle Korhonen
escreveu:
Interesting - I happen to think it's a great pattern to follow. You
try to save and then roll back if it didn't work out - that's what the
transaction management is for and Tapestry gives you a very nice way
to accomplish this easil
On Fri, Sep 11, 2009 at 3:05 PM, Thiago H. de Paula Figueiredo
wrote:
> Em Fri, 11 Sep 2009 18:30:34 -0300, Bruno Santos
> IMHO, you have to write code to do that (query the database if needed)
Well that doesn't do anything else except merely lowers the probability.
> intead of sending data to
I'm using the plain hibernate Session (shadow) and the pattern works
great for me. But I think your problem is actually in "(don't flush
the
Session after an exception occurs)". You are doing something odd since
you need to nullify the id. For a new object, the id should normally
be null. Tapestry
Em Fri, 11 Sep 2009 18:30:34 -0300, Bruno Santos
escreveu:
Hello,
Hi!
Well, the reason should be that with persist in validate() i validate
that the entity that's inserted doesn't conflict with any database
constraint like in this case and the onsucess isn't fired wich in the
case a const
Hello,
Well, the reason should be that with persist in validate() i validate
that the entity that's inserted doesn't conflict with any database
constraint like in this case and the onsucess isn't fired wich in the
case a constraint is violated it doesn't seem to make sense.
Anyway, even if i use
what is your reason, that you want to persist the enity
in the validation event?
i think its more clear to persist it in the onSuccess event method
with regards
Sven Homburg
Founder of the Chenille Kit Project
http://www.chenillekit.org
2009/9/11 Bruno Santos
> Thanks for your answer, i lea
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 wrote:
> Good evening,
>
> I have a form using a zone an
21 matches
Mail list logo
