Hi. I encountered the same problem. I started development with shale-1.0.4-SNAPHSOT a while ago and wrote my own ExceptionHandler, too. That worked so far. 3 weeks ago I upgraded to 1.0.4 and for example acegi exceptions didn't get propagated anymore to its ExceptionFilter. At this time I thought, it worked before because of a bug in the SNAPSHOT release and that got fixed in the final 1.0.4. Something changed in the way of handling exceptions I guess. I can't remember exactly what I changed to get it running in 1.0.4 again, but it had something todo with trowing exceptions.
In the past, I think the Shale Controller threw exceptions that were queued up in the session under FacesConstants.EXCEPTIONS_LIST. Now this isn't done anymore. I had to throw the exception explicitly in my shale exception handler to get it propagated. I would be also interested in what changed exactly and what's the right way to handle exceptions in shale... regards, Veit Ingo Düppe schrieb: > Hi, > > I guess I missed some changes in shale 1.0.4. I override the > DefaultExceptionHandling so that my backing bean can throw to types of > exceptions one of my ApplicationExceptions and the unchecked > SystemExceptions. These two types were handled by the > DefaultExceptionHandler. For instance, the application exception just > ends up in an error message on the same view. > > But now there is a responseComplete within the ShaleViewRoot (Is this > class new?) that prevents the rendering after exception handling. > > So, do I need to introduce my own ViewRoot component or what is the > recommended way to handle my exceptions? > > Regards > Ingo > >
