>> What we do here (using GNUJSP) is have a servlet read all the input, do the
>> work, and create a bean with all the output variables to substitute. It
>> puts this bean in the HttpSession and does an
>> HttpServiceResponse.sendRedirect() to the JSP which uses the bean. This
>> seems like it would be _terrible_ for performance, not only because it
>> involves two separate HTTP requests per page but also because it involves
>> completely unnecessary HttpSession operations.
>>
>
>The sendRedirect() approach works, but does have negative performance
impacts due
>to the extra round trip to the client. Howeber, I understand that most
>implementations of the 0.91 spec supported callPage(), which I thought worked
>like RequestDispatcher does in 0.92, and handles the redirection on the
server
>side.
Okay. Now if I use RequestDispatcher, I'll still need to put the beans in
the HttpSession, right? This can be an extremely expensive operation in a
distributed appserver architecture.
I've noticed some people on the list suggest things like using
ServletRequest.setAttribute() to pass data to the JSP, but doesn't this go
against the bean-centric approach JSP advocates? It seems like what you
really want are beans that last the lifecycle of the current HTTP request
only. Or am I missing something here?
-Ben
===========================================================================
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".
