Yes, this was precisely my concern. It makes sense to have a single
namespace for the JSP bean instances and the Session keys. But this was not
clear (or present) in the spec.
I'm curious as to how the JSP "page" lifespan might work. Are we to assume
that the JSP engine will explicitly unbind the bean from the session
regardless of how it was bound?
Also, I noticed that one of the docs for the JSP 0.92 ref implementation
mentions Servlet API 3.0. Is that a typo, or is 3.0 coming down the pike?
Rob
> In 0.92, it was not clearly specified where the session and request
> beans live. The most obvious interpretation was that session beans
> live in the session object and request beans live in the request
> object. Most implementations, including Sun's reference
> implementation for 0.92 placed the beans directly in the session and
> request objects respectively.
>
> Pedantically speaking this behaviour is not something you can count
> on. The question then is, what about Model 2? Clearly, there is a
> need to make the specification more concrete in this area. The final
> spec will [hopefully :-] be more precise about these semantics.
>
> abhishek
> ---
> Abhishek Chauhan, [EMAIL PROTECTED]
>
>
> "Craig R. McClanahan" wrote:
> > Yan Pujante wrote:
> >
> > > > In your JSP page, you declare a "lifespan" for the bean you
> are declaring
> > in
> > > > the USEBEAN tag. If you use a lifespan of "session", then
> any bean you s
> > tore
> > > > (in a servlet) with HttpSession.putValue() is available to
> the JSP page a
> > s a
> > > > bean under the same name you stored it with! The only
> thing you have to
> > watch
> > > > out for is to use storage key names that are legal Java
> variable names,
> > > > because (at least in the reference implementation) the
> generated Java cod
> > e
> > > > uses that name as the local variable that refers to the bean object.
> > > >
> > > > Thus, you can do things like this:
> > > >
> > > > * In a servlet, store a CustomerBean in the session like this:
> > > >
> > > > CustomerBean myCustomerBean = ....
> > > > session.putValue("customer", myCustomerBean);
> > > >
> > > > * Use ResourceDispatcher.forward() to internally redirect to
> > > > a JSP page
> > > >
> > > > * Access that bean like this:
> > > >
> > > > <USEBEAN name="customer" TYPE="CustomerBean" LIFESPAN="session">
> > > > </USEBEAN>
> > > >
> > > > Similarly, if you use LIFESPAN="page", you are requesting
> values that the
> > > > servlet has stored with HttpServletRequest.setAttribute().
> > > >
> > > > The namespaces for servlets and JSP pages are identical, so sharing
> > > > information back and forth is really easy.
> > >
> > > I completely agree with that. The only problem I see with this is that
> > > you somehow rely on the way the jsp implementation will store and
> > > retreive the beans. I know it sounds reasonable to put a
> session bean in
> > > the HttpSession and a page bean in the HttpServletRequest but
> I think if
> > > it is really the case it should be specified in the specification :)
> > >
> >
> > Check out the description of the "Model 2" access method in the
> JSP spec. In
> > part,
> > it reads:
> >
> > "In this example, the client makes a equest that is handled by
> a Java Servlet
> > . The
> > servlet generates the dynamic content -- in this example, the
> servlet uses JD
> > BC to
> > communicate with a database to obtain the content. The servlet
> then wraps th
> > e
> > dynamic content into a bean. The JavaServer Pages files
> accesses the dynamic
> > content from the bean and displays the content in the client
> web browser."
> >
> > Later on, in the description of the LIFESPAN attribute of the
> USEBEAN tag, it
> > says:
> >
> > * SESSION: If the bean is present in the current session,
> it is reused.
> > If not
> > present,
> > it is created and stored as part of the HTTP session.
> >
> > It seems pretty clear to me that the whole point of this is
> that the namespac
> > es are
> > the same. That's also the way that all the published
> implementations have de
> > alt
> > with the issue, so it's clearly understood by other
> implementors as well. Th
> > e spec
> > is not quite so obviously clear on where LIFESPAN=REQUEST beans
> are stored, b
> > ut the
> > implementations to date have agreed on that as well.
> >
> >
> >
> > > In my own implementation, I have 2 methods to do it :
> > > Jsp.getBean(javax.servlet.http.HttpServletRequest request,
> > > String bean_name,
> > > String lifespan)
> > >
> > > and
> > > Jsp.setBean(javax.servlet.http.HttpServletRequest request,
> > > String bean_name,
> > > String lifespan,
> > > Object value)
> > >
> > > and in the servlet when you want to get or set a bean in a
> lifespan you
> > > just call one of those method which encapsulate the way you
> really store
> > > a session bean or a page bean. I think it is a lot easier to
> call one of
> > > this method than to remember where to put your bean. And in fact I had
> > > to do it, because depending on the web server you are running
> it can be
> > > different (ex: with Java Web Server you CANNOT do a
> > > HttpServletRequest.setAttribute() for a page bean, because it
> is running
> > > with JSDJ2.0... so you have to "cheat").
> > >
> > > So I perfectly know that what I did is NOT part of the
> specification but
> > > I would really like to see something like that in the 1.0 spec.
> > >
> > > Yan
> > >
> >
> > IMHO, it *is* in the JSP spec -- just not in the 2.0 servlet
> API spec. In th
> > e 2.1
> > servlet API spec, you see all the pieces needed to implement this:
> >
> > * ServletRequest.getAttribute() / setAttribute() for LIFESPAN=REQUEST
> >
> > * HttpSession.getValue() / putValue() for LIFESPAN=SESSION
> > (NOTE: you do not have to "cheat" to do this one in the
> 2.0 servlet API,
> > because the session capability is already there)
> >
> > Where they are not done yet (in either spec) is what it means
> when you say
> > LIFESPAN=APPLICATION. My guess is that this will mean using
> > ServletContext.getAttribute() / setAttribute() in much the same
> manner -- you
> > pick
> > the lifespan and sharing characteristics that make sense for
> your beans, and
> > both
> > servlets and JSP pages have easy, natural access to them.
> >
> > 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".
>
===========================================================================
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".
