The logic for the Apache STRUTs tag bean:include causes a new connection to be opened to request a page to be included in the final response for a JSP. The data used to build the new request includes the session ID from the original request, which is stored in the JSESSIONID cookie for the new request. In theory, this should allow the new request to access session data that may have been created in the original request. The STRUTs code uses a call to HttpServletRequest.getRequestedSessionId() to create this JSESSIONID cookie on the new request.
WebSphere JSESSIONID cookie actually consists of the session ID itself, and the routing information for the request (which is used to ensure the request makes it back to the same servant where the session is actually being stored, also known as the affinity token). So, the JSESSIONID created by STRUTs is actually incorrect for IBM® WebSphere® Application Server v6.0
In practice, this means that any JSPs or servlets included using bean:include will not have access to any original session data created for the request. Instead the 'offshoot' new request created by this tag will cause new sessions to be created for the new request, and any information stored during processing of the offshoot request will ultimately be lost.
The STRUTs code uses a call to HttpServletRequest.getRequestedSessionId() to create this JSESSIONID cookie on the new request.The contents of getRequestedSessionId() is not guaranteed to be equal to the contents of the JSESSIONID cookie, So the struts code should just access the current request's JSESSIONID cookie and copy that information to the new cookie