You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Stefan Wachter <St...@gmx.de> on 2006/05/10 13:13:17 UTC
JAVA_HOME / JRE_HOME still necessary?
Hi all,
wouldn't it be nice if Tomcat does not need the JAVA_HOME or JRE_HOME
environment variable? After installation of the SUN-JDK these
environment variables are not set. Java is in the "path" and that's it.
While starting Tomcat the script "setclasspath.bat" checks if one of the
environment variables JAVA_HOME or JRE_HOME is set. Then one of these
variables is used to construct the execution commands and to set the
CLASSPATH environment variable such that is contains tools.jar.
As far as the execution command is concerned using one of the
HOME-variables is not necessary as long as Java is in the path.
I wonder why the classpath must contain tools.jar. Tomcat 5.5 uses the
Eclipse Java compiler for compiling JSPs. Therefore I think that
tools.jar is no more needed.
Patching "setclasspath.bat" such that it no more relies on one of the
HOME variables I started Tomcat. It seems to work as usual.
Thanks for your attention,
--Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JAVA_HOME / JRE_HOME still necessary?
Posted by Tim Funk <fu...@joedog.org>.
Some of us run many JVM's on the same machine. And for reasons which drive us
insane, java 1.1.X tends to be the first java in the PATH.
-Tim
Stefan Wachter wrote:
> Hi all,
>
> wouldn't it be nice if Tomcat does not need the JAVA_HOME or JRE_HOME
> environment variable? After installation of the SUN-JDK these
> environment variables are not set. Java is in the "path" and that's it.
>
> While starting Tomcat the script "setclasspath.bat" checks if one of the
> environment variables JAVA_HOME or JRE_HOME is set. Then one of these
> variables is used to construct the execution commands and to set the
> CLASSPATH environment variable such that is contains tools.jar.
>
> As far as the execution command is concerned using one of the
> HOME-variables is not necessary as long as Java is in the path.
>
> I wonder why the classpath must contain tools.jar. Tomcat 5.5 uses the
> Eclipse Java compiler for compiling JSPs. Therefore I think that
> tools.jar is no more needed.
>
> Patching "setclasspath.bat" such that it no more relies on one of the
> HOME variables I started Tomcat. It seems to work as usual.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Handling 404 thru web.xml
Posted by Tim Lucia <ti...@yahoo.com>.
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" <ti...@yahoo.com>
>Reply-To: "Tomcat Users List" <us...@tomcat.apache.org>
>To: "'Tomcat Users List'" <us...@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" <ti...@yahoo.com>
> >Reply-To: "Tomcat Users List" <us...@tomcat.apache.org>
> >To: "'Tomcat Users List'" <us...@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
RE: Handling 404 thru web.xml
Posted by MC Moisei <mc...@hotmail.com>.
Please read
>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.
as
I am puzzled a bit by the fact that Weblogic 8.1 implements it
differently.It seams that Weblogic does a forward too but it looks that's in
the very same thread as the original request handling and the filters are
called twice...
C
>From: "MC Moisei" <mc...@hotmail.com>
>Reply-To: "Tomcat Users List" <us...@tomcat.apache.org>
>To: users@tomcat.apache.org
>Subject: RE: Handling 404 thru web.xml
>Date: Wed, 10 May 2006 12:50:58 -0500
>
>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" <ti...@yahoo.com>
>>Reply-To: "Tomcat Users List" <us...@tomcat.apache.org>
>>To: "'Tomcat Users List'" <us...@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" <ti...@yahoo.com>
>> >Reply-To: "Tomcat Users List" <us...@tomcat.apache.org>
>> >To: "'Tomcat Users List'" <us...@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).doFilter(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(TcpConnection,
>> >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(TcpConnection,
>> >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
RE: Handling 404 thru web.xml
Posted by MC Moisei <mc...@hotmail.com>.
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" <ti...@yahoo.com>
>Reply-To: "Tomcat Users List" <us...@tomcat.apache.org>
>To: "'Tomcat Users List'" <us...@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" <ti...@yahoo.com>
> >Reply-To: "Tomcat Users List" <us...@tomcat.apache.org>
> >To: "'Tomcat Users List'" <us...@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).doFilter(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(TcpConnection,
> >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(TcpConnection,
> >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
RE: Handling 404 thru web.xml
Posted by Tim Lucia <ti...@yahoo.com>.
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" <ti...@yahoo.com>
>Reply-To: "Tomcat Users List" <us...@tomcat.apache.org>
>To: "'Tomcat Users List'" <us...@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).doFilter(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(TcpConnection,
>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(TcpConnection,
>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
RE: Handling 404 thru web.xml
Posted by MC Moisei <mc...@hotmail.com>.
Thanks Tim!
Yeah, that's pretty much what I figured out but is there a workaround for
that ?
MC
>From: "Tim Lucia" <ti...@yahoo.com>
>Reply-To: "Tomcat Users List" <us...@tomcat.apache.org>
>To: "'Tomcat Users List'" <us...@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).doFilter(Serv
>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(TcpConnection,
>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(TcpConnection,
>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
RE: Handling 404 thru web.xml
Posted by Tim Lucia <ti...@yahoo.com>.
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).doFilter(Serv
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(TcpConnection,
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(TcpConnection,
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
Handling 404 thru web.xml
Posted by MC Moisei <mc...@hotmail.com>.
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).doFilter(ServletRequest,
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(TcpConnection,
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(TcpConnection,
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
Re: JAVA_HOME / JRE_HOME still necessary?
Posted by Marc Farrow <ma...@gmail.com>.
Did I reply to the wrong thread? Or did I reply to a high-jacked thread? I
am sorry.
On 5/10/06, Marc Farrow <ma...@gmail.com> wrote:
>
> The question is: Where will Tomcat be running?
>
> If Tomcat is only running on one server, then only that server needs to be
> set up. If you are going to be running Tomcat on each machine, then
> modify/create the start up scripts to set the JAVA_HOME/JAVA_JRE paths in
> the script. (Easily done on Windows).
>
>
>
> On 5/10/06, Stefan Wachter <St...@gmx.de> wrote:
> >
> > Hi Tim (et al.),
> >
> > ok, I understand the necessity for using different JDKs. I thought that
> > adjusting the JAVA_HOME environment variable for certain situations
> > might be the same effort as adjusting the PATH environment variable.
> >
> > Maybe an option would be to use the JAVA_HOME/JRE_HOME variables if they
> > are present and to rely on the path if they are absent?
> >
> > What about tools.jar? Is it needed?
> >
> > Grettings,
> > --Stefan
> >
> > PS: I have to write a setup for an application that uses Tomcat. Tomcat
> > is running for end users on their local machines and not on an
> > administrated server. I think the average end user should not be forced
> > to set an environment variable.
> >
> >
> > Tim Lucia wrote:
> > > What about multiple JREs or JDKs on your system? Unlike Microsoft
> > products,
> > > you can actually have multiple versions of Java on your system
> > coexisting
> > > peacefully. Try installing the public beta of IE 7--and you are now
> > running
> > > beta software in the core of your OS (assuming of course you have a
> > Windows
> > > desktop ;-)
> > >
> > > Also, for security reasons, daemon processes and/or services should
> > not
> > > require or rely on PATH variables.
> > >
> > > Tim
> > >
> > > -----Original Message-----
> > > From: Stefan Wachter [mailto:Stefan.Wachter@gmx.de]
> > > Sent: Wednesday, May 10, 2006 7:13 AM
> > > To: users@tomcat.apache.org
> > > Subject: JAVA_HOME / JRE_HOME still necessary?
> > >
> > > Hi all,
> > >
> > > wouldn't it be nice if Tomcat does not need the JAVA_HOME or JRE_HOME
> > > environment variable? After installation of the SUN-JDK these
> > > environment variables are not set. Java is in the "path" and that's
> > it.
> > >
> > > While starting Tomcat the script "setclasspath.bat " checks if one of
> > the
> > > environment variables JAVA_HOME or JRE_HOME is set. Then one of these
> > > variables is used to construct the execution commands and to set the
> > > CLASSPATH environment variable such that is contains tools.jar.
> > >
> > > As far as the execution command is concerned using one of the
> > > HOME-variables is not necessary as long as Java is in the path.
> > >
> > > I wonder why the classpath must contain tools.jar . Tomcat 5.5 uses
> > the
> > > Eclipse Java compiler for compiling JSPs. Therefore I think that
> > > tools.jar is no more needed.
> > >
> > > Patching "setclasspath.bat" such that it no more relies on one of the
> > > HOME variables I started Tomcat. It seems to work as usual.
> > >
> > > Thanks for your attention,
> > > --Stefan
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
>
> --
>
> Marc Farrow
>
--
Marc Farrow
Re: JAVA_HOME / JRE_HOME still necessary?
Posted by Marc Farrow <ma...@gmail.com>.
The question is: Where will Tomcat be running?
If Tomcat is only running on one server, then only that server needs to be
set up. If you are going to be running Tomcat on each machine, then
modify/create the start up scripts to set the JAVA_HOME/JAVA_JRE paths in
the script. (Easily done on Windows).
On 5/10/06, Stefan Wachter <St...@gmx.de> wrote:
>
> Hi Tim (et al.),
>
> ok, I understand the necessity for using different JDKs. I thought that
> adjusting the JAVA_HOME environment variable for certain situations
> might be the same effort as adjusting the PATH environment variable.
>
> Maybe an option would be to use the JAVA_HOME/JRE_HOME variables if they
> are present and to rely on the path if they are absent?
>
> What about tools.jar? Is it needed?
>
> Grettings,
> --Stefan
>
> PS: I have to write a setup for an application that uses Tomcat. Tomcat
> is running for end users on their local machines and not on an
> administrated server. I think the average end user should not be forced
> to set an environment variable.
>
>
> Tim Lucia wrote:
> > What about multiple JREs or JDKs on your system? Unlike Microsoft
> products,
> > you can actually have multiple versions of Java on your system
> coexisting
> > peacefully. Try installing the public beta of IE 7--and you are now
> running
> > beta software in the core of your OS (assuming of course you have a
> Windows
> > desktop ;-)
> >
> > Also, for security reasons, daemon processes and/or services should not
> > require or rely on PATH variables.
> >
> > Tim
> >
> > -----Original Message-----
> > From: Stefan Wachter [mailto:Stefan.Wachter@gmx.de]
> > Sent: Wednesday, May 10, 2006 7:13 AM
> > To: users@tomcat.apache.org
> > Subject: JAVA_HOME / JRE_HOME still necessary?
> >
> > Hi all,
> >
> > wouldn't it be nice if Tomcat does not need the JAVA_HOME or JRE_HOME
> > environment variable? After installation of the SUN-JDK these
> > environment variables are not set. Java is in the "path" and that's it.
> >
> > While starting Tomcat the script "setclasspath.bat" checks if one of the
> > environment variables JAVA_HOME or JRE_HOME is set. Then one of these
> > variables is used to construct the execution commands and to set the
> > CLASSPATH environment variable such that is contains tools.jar.
> >
> > As far as the execution command is concerned using one of the
> > HOME-variables is not necessary as long as Java is in the path.
> >
> > I wonder why the classpath must contain tools.jar. Tomcat 5.5 uses the
> > Eclipse Java compiler for compiling JSPs. Therefore I think that
> > tools.jar is no more needed.
> >
> > Patching "setclasspath.bat" such that it no more relies on one of the
> > HOME variables I started Tomcat. It seems to work as usual.
> >
> > Thanks for your attention,
> > --Stefan
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
Marc Farrow
Re: JAVA_HOME / JRE_HOME still necessary?
Posted by Stefan Wachter <St...@gmx.de>.
Hi Tim (et al.),
ok, I understand the necessity for using different JDKs. I thought that
adjusting the JAVA_HOME environment variable for certain situations
might be the same effort as adjusting the PATH environment variable.
Maybe an option would be to use the JAVA_HOME/JRE_HOME variables if they
are present and to rely on the path if they are absent?
What about tools.jar? Is it needed?
Grettings,
--Stefan
PS: I have to write a setup for an application that uses Tomcat. Tomcat
is running for end users on their local machines and not on an
administrated server. I think the average end user should not be forced
to set an environment variable.
Tim Lucia wrote:
> What about multiple JREs or JDKs on your system? Unlike Microsoft products,
> you can actually have multiple versions of Java on your system coexisting
> peacefully. Try installing the public beta of IE 7--and you are now running
> beta software in the core of your OS (assuming of course you have a Windows
> desktop ;-)
>
> Also, for security reasons, daemon processes and/or services should not
> require or rely on PATH variables.
>
> Tim
>
> -----Original Message-----
> From: Stefan Wachter [mailto:Stefan.Wachter@gmx.de]
> Sent: Wednesday, May 10, 2006 7:13 AM
> To: users@tomcat.apache.org
> Subject: JAVA_HOME / JRE_HOME still necessary?
>
> Hi all,
>
> wouldn't it be nice if Tomcat does not need the JAVA_HOME or JRE_HOME
> environment variable? After installation of the SUN-JDK these
> environment variables are not set. Java is in the "path" and that's it.
>
> While starting Tomcat the script "setclasspath.bat" checks if one of the
> environment variables JAVA_HOME or JRE_HOME is set. Then one of these
> variables is used to construct the execution commands and to set the
> CLASSPATH environment variable such that is contains tools.jar.
>
> As far as the execution command is concerned using one of the
> HOME-variables is not necessary as long as Java is in the path.
>
> I wonder why the classpath must contain tools.jar. Tomcat 5.5 uses the
> Eclipse Java compiler for compiling JSPs. Therefore I think that
> tools.jar is no more needed.
>
> Patching "setclasspath.bat" such that it no more relies on one of the
> HOME variables I started Tomcat. It seems to work as usual.
>
> Thanks for your attention,
> --Stefan
>
>
>
>
> ---------------------------------------------------------------------
> 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
RE: JAVA_HOME / JRE_HOME still necessary?
Posted by Tim Lucia <ti...@yahoo.com>.
What about multiple JREs or JDKs on your system? Unlike Microsoft products,
you can actually have multiple versions of Java on your system coexisting
peacefully. Try installing the public beta of IE 7--and you are now running
beta software in the core of your OS (assuming of course you have a Windows
desktop ;-)
Also, for security reasons, daemon processes and/or services should not
require or rely on PATH variables.
Tim
-----Original Message-----
From: Stefan Wachter [mailto:Stefan.Wachter@gmx.de]
Sent: Wednesday, May 10, 2006 7:13 AM
To: users@tomcat.apache.org
Subject: JAVA_HOME / JRE_HOME still necessary?
Hi all,
wouldn't it be nice if Tomcat does not need the JAVA_HOME or JRE_HOME
environment variable? After installation of the SUN-JDK these
environment variables are not set. Java is in the "path" and that's it.
While starting Tomcat the script "setclasspath.bat" checks if one of the
environment variables JAVA_HOME or JRE_HOME is set. Then one of these
variables is used to construct the execution commands and to set the
CLASSPATH environment variable such that is contains tools.jar.
As far as the execution command is concerned using one of the
HOME-variables is not necessary as long as Java is in the path.
I wonder why the classpath must contain tools.jar. Tomcat 5.5 uses the
Eclipse Java compiler for compiling JSPs. Therefore I think that
tools.jar is no more needed.
Patching "setclasspath.bat" such that it no more relies on one of the
HOME variables I started Tomcat. It seems to work as usual.
Thanks for your attention,
--Stefan
---------------------------------------------------------------------
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