You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Paul Yunusov <py...@rogers.com> on 2002/12/02 04:40:09 UTC

Re: Bezerk - tomcat calls JSP twice ?

On Sunday 01 December 2002 10:23 pm, Stephen Riek wrote:
> I'm either still suffering from the effects of Saturday night or really
> didn't understand something about Tomcat, because the following has me
> completely surprised and unable to explain.
> I have a very very simple JSP "/Products/index.jsp" as follows -
> <%
> int i = 1;
> System.out.println("JSP PAGE DEBUGGING ************************************
> " + i); String pathSuffix = null;
> if (request.getParameter("pathSuffix")!=null) {
>  pathSuffix = request.getParameter("pathSuffix");
>  System.out.println("JSP : request PARAMETER set in URL    : " +
> pathSuffix); }
> System.out.println("JSP : pathSuffix                      : " +
> pathSuffix); %>
>
> I open the page /Products/index.jsp?pathSuffix=helloworld in my browser
> and the following appears at the Tomcat console -
>
> JSP PAGE DEBUGGING ************************************ 1
> JSP : request PARAMETER set in URL    : helloworld
> JSP : pathSuffix                      : helloworld
>
> No surprise so far.
>
> But then I change 'i' from 1 to 2 in the JSP and hit browser "refresh"
> and the following appears in the Tomcat  console -
>
> JSP PAGE DEBUGGING ************************************ 2
> JSP : request PARAMETER set in URL    : helloworld
> JSP : pathSuffix                      : helloworld
>
> JSP PAGE DEBUGGING ************************************ 2
> JSP : pathSuffix                      : null
>
> What on earth is happening here in the last 2 lines ? Is the JSP being
> called twice ?
>
> Further testing has shown that this occurs:
>
> a. If I do not change the JSP and issue the same request to the JSP,
>     which makes me suspect it is related to caching somehow.
> b. Even if I change the JSP, but the request parameter is the same.
>
> This is completely and utterly bizarre. Any output to the browser is
> NOT duplicated so it doesn't appear to have much effect but it's very
> worrying for me, not being able to explain it.
>
> Could somebody please shed light on this ? Or am I still hungover ?
>
> Stephen.
>
>
>
>
> ---------------------------------
> With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits
> your needs

Might be the hangover - I get correct output when I follow your steps and 
refresh with the parameter still in the URL and without too. I use Tomcat 
4.1.12.
My output with the parameter in the URL:

JSP PAGE DEBUGGING ************************************ 1
JSP : request PARAMETER set in URL    : helloworld
JSP : pathSuffix                      : helloworld
JSP PAGE DEBUGGING ************************************ 2
JSP : request PARAMETER set in URL    : helloworld
JSP : pathSuffix                      : helloworld

Paul

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Bezerk - tomcat calls JSP twice ?

Posted by Jacob Kjome <ho...@visi.com>.
At 03:53 AM 12/2/2002 +0000, you wrote:
>If a Filter makes a call to a page using for example 
>RequestDispatcher.forward("/Products/index.jsp"), will that request 
>dispatcher bypass any filters, or will it still be subject to all filter 
>rules ?

The filters will be bypassed.  Quoting Craig R. McClanahan....

"If your app uses a request dispatcher, you'll find that filters
   and authentication are *not* applied to the dispatched request.
   They are only applied on the original request from the client."

Jake 

Re: Bezerk - tomcat calls JSP twice ?

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Mon, 2 Dec 2002, Stephen Riek wrote:

>
> If a Filter makes a call to a page using for example
> RequestDispatcher.forward("/Products/index.jsp"), will that request
> dispatcher bypass any filters, or will it still be subject to all filter
> rules ?
>

In Servlet 2.3 (i.e. Tomcat 4.x), Filters are not invoked when you do a
RequestDispatcher.forward() or RequestDispatcher.include().  They are only
invoked on the original request.

In Servlet 2.4 (i.e. Tomcat 5), you can use an additional web.xml
configuration element that requests filters even on RD calls.  For
backwards compatibility, the default behavior will continue to be omitting
them.

>
> Stephen.
>

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Bezerk - tomcat calls JSP twice ?

Posted by Stephen Riek <st...@yahoo.co.uk>.
Thanks for the reply Paul. 
> Might be the hangover - I get correct output when I follow your steps and 
> refresh with the parameter still in the URL and without too. I use Tomcat 
> 4.1.12.
> My output with the parameter in the URL:
> 
> JSP PAGE DEBUGGING ************************************ 1
> JSP : request PARAMETER set in URL : helloworld
> JSP : pathSuffix : helloworld
> JSP PAGE DEBUGGING ************************************ 2
> JSP : request PARAMETER set in URL : helloworld
> JSP : pathSuffix : helloworld

Right, which is what I would expect, and what I used to get in my webapps.

I used Filters in my current webapp (which is exhibiting the bizarre behaviour) previously and the Filters used RequestDispatchers. However, I've since removed the filters. 

OK, I just solved it - I completely deleted the "work" directory of Tomcat and restarted Tomcat and now it seems to be working correctly. Sorry for the noise :(

Can I please check the following then,

If a Filter makes a call to a page using for example RequestDispatcher.forward("/Products/index.jsp"), will that request dispatcher bypass any filters, or will it still be subject to all filter rules ? 

Sorry for the noise. I don't know why I was getting the strange results. Even if a Filter was being cached in 'work' (even after restarting Tomcat), it shouldn't have been called at all because I'd removed all the Filter-mappings from web.xml

Stephen.

 


 




---------------------------------
With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs