File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Tomcat and the fly likes Exception handling in Filter Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Tomcat
Bookmark "Exception handling in Filter" Watch "Exception handling in Filter" New topic
Author

Exception handling in Filter

Adrian Bustos
Greenhorn

Joined: Apr 25, 2011
Posts: 8
Hi,

This topic is related to one I previously posted (Exception handling in Faces Filter).

As it says... I want to catch every exception inside a catch on a Filter I wrote, this exception will be store temporally in a session bean and treated in a differente way than usual.
My filter ended up looking like this...




This keeps what I assume is some error flag or something as true but does not raise the 500 error code to the container thus avoiding the page redirection. Exactly what I needed to do.
Using Tomcat 6x within Eclipse works ok.
But when I run the same Tomcat installation as standalone my application (wich was previously packaged as a WAR file and deployed in the webapps directory) redirects to the 500 error page.

It's really odd to me because, as I said, i'm using the same Tomcat installation.

Any ideas of what the cause could be?
Is there a difference between the way Eclipse starts the tomcat and the way it starts by executing the "run.bat"?
Is there another way to let the servlet know that an exception must not be raised as a 500 error code?
Would that other way keep that internal error flag used by the a4j:queue JSF component to raise the "onerror" event?


Thanks in advance






Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

There seems to be a fundamental flaw in your concept.

"doFilter" percolates through the filters until it reaches what is, in effect, the final filter: sending the request to the target servlet, then returning the response.

If the exception should occur before a response is generated, you only have half of the request/response cycle accounted for. You really do need something better than a sendRedirect(null) to allow for that.

As far as frameworks go, yes, the classpaths inside Eclipse do vary over running stand-alone, and even more so considering that if you're using WTP it's a flawed implementation of Tomcat. I have seen odd behavior while debugging filters.


Customer surveys are for companies who didn't pay proper attention to begin with.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Exception handling in Filter