Note 1 : From the Servlet 2.2 API :

" [...]
To allow RequestDispatcher objects to be obtained using relative paths,
paths which are not

relative to the root of the ServletContext but instead are relative to the
path of the current

request, the following method is provided in the ServletRequest interface:

. getRequestDispatcher

The behavior of this method is similar to the method of the same name in the
ServletContext,

however it does not require a complete path within the context to be given
as part of the argument to

operate. The servlet container can use the information in the request object
to transform the given

relative path to a complete path. For example, in a context rooted at '/', a
request to

/garden/tools.html, a request dispatcher obtained via

ServletRequest.getRequestDispatcher("header.html") will behave exactly like

a call to ServletContext.getRequestDispatcher("/garden/header.html").

[...] "



Note 2 : We'll also need to provide support for getNamedDispatcher() method
...

-Vincent

----- Original Message -----
From: "Vincent Massol" <[EMAIL PROTECTED]>
To: "Jon Belinfante" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Tuesday, July 03, 2001 11:53 AM
Subject: Re: Help :: Problem testing Servlet methods that forward to JSPs


>
> ----- Original Message -----
> From: "Jon Belinfante" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; "Vincent Massol"
> <[EMAIL PROTECTED]>
> Sent: Tuesday, July 03, 2001 11:12 AM
> Subject: Help :: Problem testing Servlet methods that forward to JSPs
>
>
> > I have a Servlet method that as follows that is meant to do no more then
> forward
> > to a test JSP page called WibbleWobble
> >
>
> --------------------------------------------------------------------------
> ---------------------------------------
> >
> >      protected void doPost(
> >           HttpServletRequest request,
> >           HttpServletResponse response)
> >                throws ServletException, java.io.IOException
> >      {
> >           System.out.println ("Starting : " +new Date());
> >           try
> >           {
> >
> >                String forwardURL = ("/WibbleWobble.jsp");
> >                RequestDispatcher dispatcher =
> request.getRequestDispatcher(
> > forwardURL );
> >           dispatcher.forward(request, response );
> >
>
>
> Ok, here is the story ... :)
>
> 1/ If you look at the Tomcat implementation (for Tomcat 3.x and before
> only - It is fixed for later version as they had to fix this to support
> Servlet 2.3 Filters), you'll see that the forward() and include() methods
do
> a cast of the request object to their own internal object. As the Request
> wrapper does not implement this internal object, it fails.
>
> 2/ The solution I have found for this was to wrap the Servlet Context. But
> in order to wrap the servlet context I also had to wrap the Config object.
> So that config.getServletContext() would return the wrapped context and
then
> config.getServletContext().getRequestDispatcher() would return the wrapped
> dispatcher. Thus when you would call forward() or include() on that
wrapped
> dispatcher it would actually pass the *original* request to the real
> dispatcher foward() or include() method !
>
> 3/ Apparently I have forgotten that there is another way to get a request
> dispatcher ! Through the request, like request.getDispatcher() ! This is a
> bug which has *not* been corrected. I'll correct it asap. In the meantime,
> you can use the following, which will work (as evidenced in the Cactus
suite
> of tests) :
>
> String forwardURL = ("/WibbleWobble.jsp");
> RequestDispatcher dispatcher =
> getConfig().getServletContext().getRequestDispatcher(forwardURL);
> dispatcher.forward(request, response );
>
> Note that you will need to have an init in your test method so that
> getConfig() returns the wrapped config object (as you were already doing)
:
>
> SecurityServlet servlet = new SecurityServlet();
> servlet.init(config); <-- needed
> servlet.doPost( request, response );
>
> Thanks to both of you for this bug discovery and sorry Jari, I have
probably
> skipped your mail that already mentionned that problem (or maybe I simply
> did not understand the issue at that time) ... I'll correct it quickly ...
>
> -Vincent
>
>

Reply via email to