Error handling - are these bugs with myfaces ?

[Co...@hydro.qc.ca]

I have found some unexpected behaviour with regards to error handling, both
with error mapping in web.xml
as well as with the Error page tag in jsp's.
 
 
Error mapping in web.xml:
1) I cannot map custom errors in web.xml since all the errors thrown seem to
be wrapped with a FacesException
2) I have mapped FacesException to an ErrorHandlerServlet, which is called
properly when an exception is thrown from
    the constructor of my backing bean. The only thing is I can't do
redirect or forward from the servlet since the "response is already
committed".
3) Despite having thrown a runtime exception from the constructor of my
backing bean, the jsp continues to be processed...albeit with null values
    from my backing bean....I get loads of 'parent is null' messages on my
console.
 
 
 
Error page tag in jsp:
1) This tag works perfectly when not being used in jsf'ized jsp.
2) When used in a jsf'ized page, I get the 'response already committed'
message...and the error page is never loaded.
 
 
Could someone please tell me if this is the desired behaviour, or if some of
these observations are bugs ?
If need be, I can post the code for all of this.
 
 
 
Note: I realize that the intended pattern for database access is to have the
lookups being done behind action listeners. If all
         our db access was done like this, then we could simply redirect to
error pages via the navigation handler in faces-config...
         but this is not always possible. Many times, db access is triggered
in constructors of backing beans and we need an
         alternate form of error handling (ie: redirecting to an error page)
after an exception was thrown from the constructor.
 
 
Thanks in advance,
 
Mark

Re: Error handling - are these bugs with myfaces ?

[Heath Borders <he...@gmail.com>]

Try running your JSP outside of Tiles.  I'm guessing you're getting a
"response already committed" because you are flushing your Tiles
content somewhere.  Make sure that all your Tiles do not have
flush="true", as this will cause content to start being pushed over
the wire.

On Thu, 9 Dec 2004 11:32:43 -0500, Cote.Mark@hydro.qc.ca
<Co...@hydro.qc.ca> wrote:
> 
> I have found some unexpected behaviour with regards to error handling, both
> with error mapping in web.xml
> as well as with the Error page tag in jsp's.
>  
>  
> Error mapping in web.xml:
> 1) I cannot map custom errors in web.xml since all the errors thrown seem to
> be wrapped with a FacesException
> 2) I have mapped FacesException to an ErrorHandlerServlet, which is called
> properly when an exception is thrown from
>     the constructor of my backing bean. The only thing is I can't do
> redirect or forward from the servlet since the "response is already
> committed".
> 3) Despite having thrown a runtime exception from the constructor of my
> backing bean, the jsp continues to be processed...albeit with null values
>     from my backing bean....I get loads of 'parent is null' messages on my
> console.
>  
>  
>  
> Error page tag in jsp:
> 1) This tag works perfectly when not being used in jsf'ized jsp.
> 2) When used in a jsf'ized page, I get the 'response already committed'
> message...and the error page is never loaded.
>  
>  
> Could someone please tell me if this is the desired behaviour, or if some of
> these observations are bugs ?
> If need be, I can post the code for all of this.
>  
>  
>  
> Note: I realize that the intended pattern for database access is to have the
> lookups being done behind action listeners. If all
>          our db access was done like this, then we could simply redirect to
> error pages via the navigation handler in faces-config...
>          but this is not always possible. Many times, db access is triggered
> in constructors of backing beans and we need an
>          alternate form of error handling (ie: redirecting to an error page)
> after an exception was thrown from the constructor.
>  
>  
> Thanks in advance,
>  
> Mark


-- 
If you don't have a GMail account, I probably have 5 invites.  Just ask!
-Heath Borders-Wing
hborders@mail.win.org