Randy Belknap wrote:
> "Craig R. McClanahan" wrote:
>
> > request.setAttribute("myBean", myBean);
> > RequestDispatcher rd =
>getServletContext().getRequestDispatcher("/nextpage.jsp");
> > rd.forward(request, response);
>
> Craig,
>
> I thought I read in one of your posts that an upcoming version of the
> spec (either 2.2 servlet or 1.1 jsp) specifies that the request and
> response objects must be the original request/response objects. (I
> looked for the post, but couldn't find it.) I took this to mean that
> you couldn't add something to the request and then forward it on. I
> assume I misread the email?
>
Wow, somebody actually reads my scribblings! :-)
You remember correctly ... this restriction was first added in the "Clarifications to
the
Servlet API 2.1 Spec" in the back of the JSP 1.0 specification, and are formalized in
Section 8.2 of the Servlet API 2.2pr spec that is currently available. It says:
To use a request dispatcher, a developer needs to call
either the include or forward method of the RequestDispatcher
interface using the request and response arguments that were
passed in via the service method of the Servlet interface.
This restriction allows a servlet container implementation to assume that it's own
private
implementations of HttpServletRequest and HttpServletResponse, which have "insider
knowledge" of the rest of the container as well as implementation-specific method
calls,
are still being used even when handling a forward or include request. Violating this
restriction usually causes a ClassCastException inside the servlet engine.
Note that the code I recommended above does *not* violate this restriction, because the
original request object is still being used in the forward() call. The
ServletRequest.setAttribute() call was added to the API for precisely this kind of
purpose
-- to allow a servlet (or JSP page) to add some user objects to the request and then
pass
them on to a different servlet or JSP page. It enables a style of web app development
that I really like (separating business logic from presentation logic). In the JSP
0.92
spec this was called the "Model 2" approach -- in 1.0 and 1.1, it is called the
"Redirecting Requests" approach.
Conceptually, this is almost exactly like storing user data in an HttpSession with the
putValue() call. Calling session.putValue() does not change which session you are
talking
about, it only modifies the properties of that session. Calling request.setAttribute()
does the same thing -- adds some additional information to the existing request
instance.
Using request.setAttribute() is appropriate when you only need these objects for the
duration of the current request. These objects will "disappear" on subsequent
requests,
because the servlet engine will give you a different request instance to be processed
the
next time your doGet() or doPost() method is called.
I hope that clears things up a bit.
Craig
===========================================================================
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
