Thanks for your reply Dan.
My application is rather simplistic from a persistence point of view,
meaning that I want all persistence actions from a request to be atomic.
Of course I could move the commit calls out of the RequestCycle class
which would solve this particular problem.
But does that mean there is no way to properly handle an exception
occuring in RequestCycle#endOfRequest to redirect to an error page or
add error messages to the current page?
I figured this should be doable, or could it mean that I broke something
with my architecture?
The Sanity Resort <http://sanityresort.blogspot.com/>
Am 24.09.2011 12:46, schrieb Dan Retzlaff:
So you open both a session and a transaction at the beginning of a request,
and commit/close them at the end? I think it's more common to only have the
session last through the request, and to have transactions started/committed
around DAO or controller methods. This gives your app more control over
transaction boundaries and exceptions. Since this can mean lots of
begin/try/commit/finally/rollback stuff, it's also common to use AOP (e.g.
from Guice or Spring) to do that stuff without code for each instance.
Dan
On Sat, Sep 24, 2011 at 1:47 AM, Christian Huber<hub...@butterbrot.org>wrote:
Hi again,
sorry for reposting, but as I am still struggling with this I thought I try
bumping this thread.
Any hints would be very welcome.
Cheers, Chris
The Sanity
Resort<http://sanityresort.blogspot.**com/<http://sanityresort.blogspot.com/>
Am 19.09.2011 19:50, schrieb Christian Huber:
Hi all,
I just noticed that exceptions occuring in onEndRequest of a RequestCycle
somehow do not reflect on the respone page.
I am using an AjaxFallbackButton and the OSIV pattern and thus commit my
database changes in onEndRequest, now if an exception occurs here I do get a
log entry but I cannot get my application to display the corresponding error
to the user.
Adding a message to the feedback panel does not help as the message gets
displayed on the following request but not the current one. I also tried
using various AbortExceptions like RedirectToUrlException,
RestartResponseException or AbortWithWebErrorCodeException**. This did
improve the situation as far as the request did get aborted but there is
still no visual display of the error.
Setting the ResponsePage directly and/or setting redirect to true did not
change anything.
This sounds like a common problem and so I guess there is an easy solution
to it, but I just don't get it right now, so any pointers are welcome.
Thanks, Chris
