Provide access to critical information in the Portal request from another application context on web containers like WebSphere 5.1.x

Some webcontainers like WebSphere 5.x derive critical information of the HttpServletRequest dynamically from the current application context.
This means that in an invoked portlet application, the original Portal request, as stored in the RequestContext, for example doesn't returns the Portal contextPath, servletPath and HttpSession of the Portal application. You'll get the same object references as in the current application HttpServletRequest.
Because of this, simple things as portal level login through a custom portlet isn't possible in these web containers.

To solve this, an additional PortalRequest wrapper will be used which registers the initial (portal) object references from a supplied request and always returns those,
instead of delagating to the wrapped request.
Which wrapper is used is handled by a new PortalRequestFactory which can be specified in the springframework configuration.
For other web containers like Tomcat which doesn't have this "problem", nothing has to be specified (none is by default), in which case the request will be wrapped in an HttpServletRequestWrapper to maintain the same level of wrapping (needed for easy access to the original request in ServletPortletInvoker.

An initial version of PortalRequest wrapper as well as a PortalRequestFactoryImpl will be supplied which has been tested on WebSphere 5.x.
This version might not yet be complete though: it currently only stores references to the contextPath, servletPath and session.
Other elements possibly might need to be stored too.

Note: deployment of Jetspeed-2 on WebSphere (5.x) is in progress but not complete yet...