Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:In-Reply-To:X-MimeOLE;
  b=D1Nn88K94vCydsIXWvSJsPiP5au/hNiLrmwTim9FGgJKaHgbyUui7atUgXnwA0TMkIDWFius0WSI4N+ZngBF/FKvQXgp34Kc2amvV20OnBWche2ILhzqcczSBoAsDtj/izTmEx9HCB5HeEgKjrZVRXlxwbQWOsU7D3gQtVPfQ4I=
  ;
From: "Tim Lucia" <timlucia@yahoo.com>
To: "'Tomcat Users List'" <users@tomcat.apache.org>
Subject: RE: Handling 404 thru web.xml
Date: Wed, 10 May 2006 15:22:46 -0400
Message-ID: <00aa01c67467$1eebef30$3a0119ac@tim>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcZ0WmUttunDcfoiS+KlhwDas5xWGQAC4xMA
In-Reply-To: <BAY103-F13C013B878687A2EE7B737D5AE0@phx.gbl>

It must be Struts that is sending the 404, as there is a wildcard mapping
for *.do to the ActionServlet.  When all the stack frames are popped off,
Tomcat detects the 404 return code and forwards to the error page.

If you redirect to the error page, then the client (browser) will make the
request and your filter chain should be invoked.

Sorry I didn't read the stack trace all that carefully, and the package
names are gone anyway, making it difficult to know for sure where your code
starts / Tomcat's ends.

And I should probably have said "or" below, as in you don't need both a
default page and a 404 page, unless you want to catch non-struts 404s.
I.e., default page will catch /timWasHere.do but will not catch /timWasHere.

Tim

-----Original Message-----
From: MC Moisei [mailto:mcmoisei@hotmail.com] 
Sent: Wednesday, May 10, 2006 1:51 PM
To: users@tomcat.apache.org
Subject: RE: Handling 404 thru web.xml

Tim I appreciate you're so prompt on this isssue.

If you look to the second stack trace I sent you'd see that none of my
filters are executed when the forward is happening.

I'm not keen at all for a redirect what I'd need is to have the filters
executed since the put some stuff in the request, stuff that is very
important for the struts actions/controllers. What I don't understand is why
on the forward case even thought the ApplicationFilterChain.doFilter
() is called none of the filters are called. After all shouldn't error
interception be on same thread as the original thread ?

Your solution will definetely work and that's going to be the way out.

I am puzzled a bit by the fact that Weblogic 8.1 implements it differently
and that's a certain thing I can tell you for sure, Weblogic does a redirect
and that solves my problems on that environment.

MC


>From: "Tim Lucia" <timlucia@yahoo.com>
>Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
>To: "'Tomcat Users List'" <users@tomcat.apache.org>
>Subject: RE: Handling 404 thru web.xml
>Date: Wed, 10 May 2006 13:20:44 -0400
>
>Workaround?  You speak as if it is broken, when it is behaving as it 
>should.
>
>If you look at the stack while inside the error page, you will see your 
>chain of filters on the stack.  They've already done the request side 
>and are now waiting for chain.doFilter(request, response) to return.
>
>If you are looking to redirect all 404/not found pages to your default 
>page, then you can do that (using Struts) by marking portal.do as the 
>default mapping.  And, you can have a home/default action with a 
><forward name="home" path="/portal.do" redirect="true"/>.  This action 
>can be as simple as
>
><action path="/NotFound" type="org.apache.struts.actions.ForwardAction"
>parameter="home"/>
>
>And then, in your web.xml, use /NotFound as the target of your error page.
>
>At any rate, setting the 'redirect="true"' attribute on the forward 
>will cause the struts controller to sendRedirect() instead of forward().
>
>Tim
>
>-----Original Message-----
>From: MC Moisei [mailto:mcmoisei@hotmail.com]
>Sent: Wednesday, May 10, 2006 12:27 PM
>To: users@tomcat.apache.org
>Subject: RE: Handling 404 thru web.xml
>
>Thanks Tim!
>
>Yeah, that's pretty much what I figured out but is there a workaround 
>for that ?
>
>MC
>
>
>
>
> >From: "Tim Lucia" <timlucia@yahoo.com>
> >Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
> >To: "'Tomcat Users List'" <users@tomcat.apache.org>
> >Subject: RE: Handling 404 thru web.xml
> >Date: Wed, 10 May 2006 12:12:17 -0400
> >
> >A redirect would change the status code returned to the user agent.  
> >It does not go through the filters because it is forwarded, and as 
> >such is part
>of
> >the same request, not a new request.
> >
> >
> >Tim
> >
> >-----Original Message-----
> >From: MC Moisei [mailto:mcmoisei@hotmail.com]
> >Sent: Wednesday, May 10, 2006 11:59 AM
> >To: users@tomcat.apache.org
> >Subject: Handling 404 thru web.xml
> >
> >Hi,
> >
> >Do you know of any issue involving error handling in tomcat (5.5.9) ?
> >
> >Here's the deal. I defined in my web.xml the following entry
> >
> ><error-page>
> >      <error-code>404</error-code>
> >     <location>/portal.do</location>
> ></error-page>
> >
> >When I call, say portal1.do, a page that doesn't exists I get a 
> >forward
>to
> >the portal.do the thing with the forward is seems that it doesn't go 
> >thru the application filters again. And why this is not a redirect ? 
> >The
>browser
> >address stays portal1.do instead of portal.do...
> >
> >Here how the stack trace looks when the portal1.do is called ( this 
> >is normal, check the second trace)
> >
> >
> >Thread [http-8585-Processor24] (Suspended)
> >	CustomServlet.service(ServletRequest, ServletResponse) line: 104
> >	ApplicationFilterChain.internalDoFilter(ServletRequest,
> >ServletResponse)
> >line: 252
> >	ApplicationFilterChain.doFilter(ServletRequest, ServletResponse)
> >line: 173
> >	FilterSecurityInterceptor.invoke(FilterInvocation) line: 84
> >	SecurityEnforcementFilter.doFilter(ServletRequest, ServletResponse,
> >FilterChain) line: 182
> >	FilterToBeanProxy.doFilter(ServletRequest, ServletResponse,
> >FilterChain)
> >line: 125
> >	ApplicationFilterChain.internalDoFilter(ServletRequest,
> >ServletResponse)
> >line: 202
> >	ApplicationFilterChain.doFilter(ServletRequest, ServletResponse)
> >line: 173
> >
> >CustomAuthenticationProcessingFilter(AbstractProcessingFilter).doFilt
> >er(Ser
>v
> >letRequest,
> >ServletResponse, FilterChain) line: 305
> >	FilterToBeanProxy.doFilter(ServletRequest, ServletResponse,
> >FilterChain)
> >line: 125
> >	ApplicationFilterChain.internalDoFilter(ServletRequest,
> >ServletResponse)
> >line: 202
> >	ApplicationFilterChain.doFilter(ServletRequest, ServletResponse)
> >line: 173
> >	HttpSessionContextIntegrationFilter.doFilter(ServletRequest,
> >ServletResponse, FilterChain) line: 225
> >	FilterToBeanProxy.doFilter(ServletRequest, ServletResponse,
> >FilterChain)
> >line: 125
> >	ApplicationFilterChain.internalDoFilter(ServletRequest,
> >ServletResponse)
> >line: 202
> >	ApplicationFilterChain.doFilter(ServletRequest, ServletResponse)
> >line: 173
> >	ContentReaderFilter.doFilter(ServletRequest, ServletResponse,
> >FilterChain)
> >line: 171
> >	ApplicationFilterChain.internalDoFilter(ServletRequest,
> >ServletResponse)
> >line: 202
> >	ApplicationFilterChain.doFilter(ServletRequest, ServletResponse)
> >line: 173
> >	RequestUtilsFilter.doFilter(ServletRequest, ServletResponse,
> >FilterChain)
> >line: 114
> >	ApplicationFilterChain.internalDoFilter(ServletRequest,
> >ServletResponse)
> >line: 202
> >	ApplicationFilterChain.doFilter(ServletRequest, ServletResponse)
> >line: 173
> >	StandardWrapperValve.invoke(Request, Response) line: 213
> >	StandardContextValve.invoke(Request, Response) line: 178
> >	StandardHostValve.invoke(Request, Response) line: 126
> >	ErrorReportValve.invoke(Request, Response) line: 105
> >	StandardEngineValve.invoke(Request, Response) line: 107
> >	CoyoteAdapter.service(Request, Response) line: 148
> >	Http11Processor.process(InputStream, OutputStream) line: 856
> >
> >Http11Protocol$Http11ConnectionHandler.processConnection(TcpConnectio
> >n,
> >Object[]) line: 744
> >	PoolTcpEndpoint.processSocket(Socket, TcpConnection, Object[]) line:
> >527
> >	LeaderFollowerWorkerThread.runIt(Object[]) line: 80
> >	ThreadPool$ControlRunnable.run() line: 684
> >	ThreadWithAttributes(Thread).run() line: 595
> >
> >
> >
> >Here how the stack trace looks on the forward to /portal.do after 404 
> >was intercepted
> >
> >
> >
> >Thread [http-8585-Processor24] (Suspended (breakpoint at line 74 in
> >CustomServlet))
> >	CustomServlet.service(ServletRequest, ServletResponse) line: 74
> >	ApplicationFilterChain.internalDoFilter(ServletRequest,
> >ServletResponse)
> >line: 252
> >	ApplicationFilterChain.doFilter(ServletRequest, ServletResponse)
> >line: 173
> >	ApplicationDispatcher.invoke(ServletRequest, ServletResponse) line:
> >672
> >	ApplicationDispatcher.processRequest(ServletRequest,
> >ServletResponse) line:
> >465
> >	ApplicationDispatcher.doForward(ServletRequest, ServletResponse)
> >line: 398
> >	ApplicationDispatcher.forward(ServletRequest, ServletResponse) line:
> >301
> >	StandardHostValve.custom(Request, Response, ErrorPage) line: 362
> >	StandardHostValve.status(Request, Response) line: 283
> >	StandardHostValve.invoke(Request, Response) line: 136
> >	ErrorReportValve.invoke(Request, Response) line: 105
> >	StandardEngineValve.invoke(Request, Response) line: 107
> >	CoyoteAdapter.service(Request, Response) line: 148
> >	Http11Processor.process(InputStream, OutputStream) line: 856
> >
> >Http11Protocol$Http11ConnectionHandler.processConnection(TcpConnectio
> >n,
> >Object[]) line: 744
> >	PoolTcpEndpoint.processSocket(Socket, TcpConnection, Object[]) line:
> >527
> >	LeaderFollowerWorkerThread.runIt(Object[]) line: 80
> >	ThreadPool$ControlRunnable.run() line: 684
> >	ThreadWithAttributes(Thread).run() line: 595
> >
> >
> >Any idea will be greatly appreciated.
> >
> >MC
> >
> >Ps.
> >On weblogic the error handling triggers a redirect and the above 
> >problem
>is
> >not present.
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org