Ray wrote:
>>Kevin Jones wrote:
>>> Wrong on both counts I'm afraid - the call can be forwarded to a resource,
>>> which will typically be a servlet or a JSP, and the call will return to you.
>>> You typically put a <code>return;</code> statement after the
>>> RequestDispatcher call,
>
> > "Unlike the include() method, control will never return to the servlet
> > that forwards the request. The forward() method passes all control to the
> > delegate servlet which..."
>
> These semantics are impossible to achieve in Java. A method in Java must
> return. When you call forward(), at some point, that function will
> return to the calling frame. Other languages, like some C compilers support
> volatile functions, or the ability to specify that a method call should not
> return. (equivalent to a branch/jmp in assembly code. Or, if you like
> BASIC, it's GOTO vs GOSUB)
I haven't been following this thread, but... I suspect what the
above refers to is that when you dispatch a request, whatever the
request has been dispatched to is expected to take care of getting a
printwriter from the HttpResponse object and sending some HTML to the
user. So by the time the method call returns, the browser that
initiated the request has already been sent a page, and no further
displaying of HTML to the browser is feasible.
This is, however, just my off-the-cuff analysis of the situation
based on what I know about how HTTP works and how servlets and
HttpResponse work. I've never even looked at the RequestDispatcher.
Steven J. Owens
[EMAIL PROTECTED]
[EMAIL PROTECTED]
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
