Rob Schoening wrote:
> > This corresponds to the direction the servlet API is headed (a
> > servlet context
> > being treated essentially as an application), so the choice of
> > "application" as
> > the term makes a lot more sense when you understand what it is
> > really doing.
> > Previous comments from Sun engineers on this topic imply that
> > this behavior (as
> > well as the corresponding behavior for session and page lifespans) will be
> > formalized in the 1.0 JSP spec.
>
> Is there some kind of consensus as to when the lifespan gets applied to the
> beans? For instance, if two JSP pages have a <usebean> declaration that
> refers to the same bean, but with different specified lifespans, what
> happens? And in the 0.92 "Model #2", how does the servlet specifiy the
> lifespan of the objects? Can it?
>
The following info relates to the 0.92 reference implementation. My
understanding is that this behavior is likely to be codified in 1.0, but of
course we have to wait and see for that. The servlet generated by the JSP page
really only uses the LIFESPAN attribute value to decide where to look for the
bean, so JSP pages that look in the wrong place will not find it. Consider the
following three scenarios:
***** Case 1 ***** "Page" LIfespan *****
JSP Page contains:
<USEBEAN NAME="foo" TYPE="MyBean" LIFESPAN="PAGE">
</USEBEAN>
Generated JSP Servlet Code does (in essence):
MyBean foo = (MyBean) request.getAttribute("foo");
Therefore your Model 2 Servlet would store this with:
MyBean foo = ...
request.setAttribute("foo", foo);
Bean Lifetime: Until the response to the current request is returned to the
user. Thus, this is only useful if you use a ResourceDispatcher (which became
RequestDispatcher in the 2.1 servlet API) to forward your request to a JSP page
-- precisely as pictured in the "Model 2" flow diagrams.
***** Case 2 -- "Session" Lifespan *****
JSP Page contains:
<USEBEAN NAME="foo" TYPE="MyBean" LIFESPAN="SESSION">
</USEBEAN>
Generated JSP Servlet Code does (in essence):
HttpSession session = request.getSession(true);
MyBean foo = (MyBean) session.getValue("foo");
Therefore your Model 2 Servlet would store this with:
HttpSession session = request.getSession(true);
MyBean foo = ...
session.putValue("foo", foo);
Bean Lifetime: Until someone removes it with session.removeValue("foo") or
until the session is invalidated.
***** Case 3 -- "Application" Lifespan *****
JSP Page contains:
<USEBEAN NAME="foo" TYPE="MyBean" LIFESPAN="APPLICATION">
</USEBEAN>
Generated JSP Servlet Code does (in essence):
MyBean foo = (MyBean) getServletContext().getAttribute("foo");
Therefore your Model 2 Servlet would store this with:
MyBean foo = ...
getServletContext().setAttribute("foo", foo);
Bean Lifetime: Until someone removes it with
getServletContext().removeAttribute("foo") or until the servlet engine shuts
down.
>
> I don't mind waiting for the 1.0 spec. But it would be really helpful to
> have some kind directon so that my apps don't get smashed by semantic
> changes in the 0.9x->1.0 transition.
>
I'm pretty confident that the above approach will be stable enough to start
designing applications for. Of course, Javasoft could repeat the "package
name" fiasco we went through with Swing and change USEBEAN back to BEAN or
something else weird -- but the lifespan model seems like it should stay pretty
close to how it works in the 0.92 reference implementation.
>
> Rob
>
Craig McClanahan
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
