You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Ate Douma (JIRA)" <je...@portals.apache.org> on 2005/08/27 02:27:28 UTC
[jira] Created: (JS2-355) Provide access to critical information in the Portal request from another application context on web containers like WebSphere 5.1.x
Provide access to critical information in the Portal request from another application context on web containers like WebSphere 5.1.x
------------------------------------------------------------------------------------------------------------------------------------
Key: JS2-355
URL: http://issues.apache.org/jira/browse/JS2-355
Project: Jetspeed 2
Type: Improvement
Components: Components Core, Container
Versions: 2.0-M4
Environment: WebSphere 5.1.1.3, Windows XP SP2
Reporter: Ate Douma
Assigned to: Ate Douma
Fix For: 2.0-M4
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...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Resolved: (JS2-355) Provide access to critical information in the Portal request from another application context on web containers like WebSphere 5.1.x
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-355?page=all ]
Ate Douma resolved JS2-355:
---------------------------
Resolution: Fixed
First version checked in.
> Provide access to critical information in the Portal request from another application context on web containers like WebSphere 5.1.x
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JS2-355
> URL: http://issues.apache.org/jira/browse/JS2-355
> Project: Jetspeed 2
> Type: Improvement
> Components: Components Core, Container
> Versions: 2.0-M4
> Environment: WebSphere 5.1.1.3, Windows XP SP2
> Reporter: Ate Douma
> Assignee: Ate Douma
> Fix For: 2.0-M4
>
> 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...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org