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 store
> > (in a servlet) with HttpSession.putValue() is available to the JSP page as 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 code
> > 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 JDBC to
communicate with a database to obtain the content. The servlet then wraps the
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 namespaces are
the same. That's also the way that all the published implementations have dealt
with the issue, so it's clearly understood by other implementors as well. The spec
is not quite so obviously clear on where LIFESPAN=REQUEST beans are stored, but 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 the 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".
