(this was posted to struts-dev, but it perhaps belongs more in struts-user until a solution is actually implemented) 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?
