bean:include breaks Servlet/JSP session

[Colin Sampaleanu <co...@Bspark.com>]

I am finding the current implementation of bean:include to be of limited
use, since any existing session is lost for the resource it accesses. This
is because the include is done by actually creating an http (or whatever
scheme) connection to the specified resource, and pulling down the content
via that connection. When the resource is accessed there is no cookie sent
or session ID on the URL, so it thinks the user is coming in on a new
session, which will often break the app (authentication is lost, some
session data is missing, etc.).

jsp:include can of course also not be used since it does not reset the
request parameters. Trying to do a jsp:include of a an action (e.g.
'/something.do') breaks, since the action servlet still thinks the user is
coming in on the original request (for the jsp page doing the include), and
doesn't know how to map the request to the proper action.

So with the current state of affairs there would seem to be no workable way
for a JSP page to do an include of some other content in the current app
that is accessed as an action.

I can see a couple of potential solutions:
1) If the include code can assume any knowledge of how session IDs are
specified on URLs, it could try to add the session ID itself. I believe that
Servlets 2.3 specifies that the session id has to come in as a param called
something like JSESSIONID. Does anybody know however if there is any
guarantee that the value there is the same value as returned by
session.getID()?
2) Do a jsp:include, but make sure the right info about which action to call
gets to ActionServlet. This could be done by having ActionServlet look for a
special parameter (e.g. 'actionPath') which if it existed would be
considered the action path to use, so instead of doing
  <jsp:include path='/something.do'/>
you would use
  <jsp:include path='/fake.do?actionPath=/something.do'/>
this has security implications, so the code should still do a 'forward' to
the right path, instead of just running the action, so any web server
security based on path still kicks in. An alternative would be to hit
another servlet entirely that does the forward.

Anybody have any thoughts on this issue?


> -----Original Message-----
> From: Immanuel, Gidado-Yisa [mailto:avm3@cdc.gov]
> Sent: October 31, 2000 1:59 PM
> To: Struts-dev (E-mail)
> Subject: some questions
> 
> 
> I'm new to the list.  I see a lot of potential for
> using Struts in my project, but there are some things
> that Struts does not quite do. Anyway, with that brief
> intro, let me get to the meat of why I'm writing:
> 
> 1. Looking at the /struts-documentation/index.html
>    it describes the 'users_guide.html' as old.  I was
>    wondering if there was something that is going to
>    replace it?
> 
>    a. If someone is working on replacing it, are they
>       going the XML/XSLT route?
> 
>    b. Shortly, I'll be sending in patches for the 'new'
>       'users_guide' which is really the old, but split
>       up into several files.
> 
> 2. I want to add a little bit of documentation about how
>    to customize the 'ActionServlet', because that seems
>    to be very important, but not discussed anywhere.
>    Also, this would address some earlier questions that
>    explain the framework a little more clearly (see:
>    UML Diagrams for Struts?).
>    a. I'll be sending patches for this shortly.
> 
> 3. I like the framework, but it is too static, meaning
>    that I 'have' to code an 'ActionForm' for every
>    form that I want, and I have to set the 'type' (i.e.
>    className) in the 'action.xml' file.  This is something
>    that I think can be done much simpler using and XML
>    representation of the 'ActionForm' bean.  This way,
>    we can generate the bean without having to generate
>    code/compile.  Also, this would be the first step in
>    generating runtime ActionForms.  If this has been done,
>    or there is any general feedback.  Please let me know.
> 
> Gidado-Yisa Immanuel
> 
>