> One way to avoid this, for your scenario, would be to write a "wrapper" class
> around the original request that passed every call except getMethod() on to
> the original request object, but always returned "GET" for getMethod(). Then,
> you could pass the wrapped request to your request dispatcher object, instead
> of the original one. Alternatively, you could just make the forwarded-to (or
> included) servlet deal correctly with either type of request.
That will fail with both Sun's JSDK and JRun. ( both make a cast to be sure
only the unmodified original request is passed.)
> > 3) In the API document, include() method in the RequestDispatcher
> > class throws IOException
> > "if the ServletOutputStream or a writer had already been obtained
> > from the response object"
> > Is this correct?
> >Hmmm, that is an interesting one that deserves a little more looking in to.
> It makes sense to have the include() method throw an IOException because it
> could have come from the service() method of the servlet that was called by
> the request dispatcher -- but the text of this description seems to be at odds
> with the earlier statement that the included servlet, via the response object,
> *does* have access to the calling servlet's ServletOutputStream or PrintWriter
> object -- even though it cannot necessarily set response headers.
I guess what it means is "both servlets must use the same - either OutputStream
or Writer".
This migh put an extra limitation on what you can do with this method... ( if you
write both classes
or can change the code - why not just call the method directly and have all the
freedom).
Costin
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
