You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bridges-dev@portals.apache.org by "James Schopp (JIRA)" <br...@portals.apache.org> on 2005/09/27 18:05:48 UTC
[jira] Created: (PB-9) Resources overewritten by portlet: need to be restored
Resources overewritten by portlet: need to be restored
------------------------------------------------------
Key: PB-9
URL: http://issues.apache.org/jira/browse/PB-9
Project: Portals Bridges
Type: Bug
Components: struts
Versions: 0.4
Environment: JBoss 4.0.2 w/ Tomcat 5x; Liferay Portal 3.6.1; Struts 1.27; JDK 1.4.2_09; WinXP
Reporter: James Schopp
Liferay uses Struts to layout the actual portal itself, and so has message resources stored in the request attributes under the Struts key Globals.MESSAGES_KEY. This gets overwritten by portlets using Struts Bridges, and causes problems later on (at leaast in Liferay) in portal rendering (since messages can longer be found).
I have created a temporary fix in Liiferay by creating my own StrutsPortlet subclass that saves off the messages before processRequest runs, and restores them afterward. However, I believe this should actually be a part of the default StrutsPortlet provided with bridges, since it could/should really affect any portal framework (potentially).
The code is VERY simple to implement. Here is the subclass that I created: it is obvious how to incorporate it into the base class:
<code>
package com.liferay.portal.apache.bridges;
import java.io.IOException;
import javax.portlet.PortletException;
import javax.portlet.PortletRequest;
import javax.portlet.PortletResponse;
import javax.servlet.http.HttpServletRequest;
import org.apache.portals.bridges.struts.StrutsPortlet;
import org.apache.struts.Globals;
/**
* LiferayStrutsPortlet this portlet adds the additional functionality (over StrutsPortlet) to restore overwritten resources.
* It works such that:
* <ul>
* <li>message resources that were in in the request BEFORE the call to processRequest are saved restored afterward such
* as to avoid conflicts with resources used for the portal itself (and other struts portlets)</li>
* </ul>
*
* @author James Schopp
*
*/
public class LiferayStrutsPortlet extends StrutsPortlet
{
protected void processRequest(PortletRequest request, PortletResponse response,
String defaultPage, String requestType) throws PortletException,
IOException
{
HttpServletRequest req = getHttpServletRequest(this, request, response);
Object objMessages = req.getAttribute(Globals.MESSAGES_KEY);
try {
super.processRequest(request, response, defaultPage, requestType);
} finally {
req.setAttribute(Globals.MESSAGES_KEY, objMessages);
}
}
}
</code>
--
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: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Commented: (PB-9) Resources overewritten by portlet: need to be restored
Posted by "James Schopp (JIRA)" <br...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/PB-9?page=comments#action_12330734 ]
James Schopp commented on PB-9:
-------------------------------
Ate,
Thanks for the reply.
I have, in fact, modified the code as it was and now "save off" ALL attributes that begin with "org.apache.struts.", and then remove those values from the request. Once I get control back (after super.processRequest() has finished), I then restore the variables that were there before. This works fine, and both Liferay and the JPetStore portlet are working perfectly now (I hadn't actually observed any issues as it was before, but I came to the same conclusion you did - that other problems could appear - and tried to head them off.)
(More testing is clearly needed though. I need more Struts portlets to try!)
The latest version of the code is contained here, and although I do agree with your statement (that the portal should protect itself), it may be useful enough to enabled/disable this functionality with a flag somewhere/somehow:
(sorry for the formatting - it looks good in Eclipse, I swear)
==============================================
package com.liferay.portal.apache.bridges;
import java.io.IOException;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;
import javax.portlet.PortletException;
import javax.portlet.PortletRequest;
import javax.portlet.PortletResponse;
import org.apache.portals.bridges.struts.StrutsPortlet;
import org.apache.struts.Globals;
import org.apache.struts.config.ModuleConfig;
/**
* LiferayStrutsPortlet this portlet adds the additional functionality (over StrutsPortlet) to restore overwritten resources.
* It works such that:
* <ul>
* <li>all request attributes whose keys begin with "org.apache.struts." that were in in the request BEFORE the call to processRequest are
* saved restored afterward such as to avoid conflicts with resources used for the portal itself (and other struts portlets)</li>
* </ul>
*
* @author James Schopp
*
*/
public class LiferayStrutsPortlet extends StrutsPortlet
{
private static String _STRUTS_PACKAGE = "org.apache.struts.";
protected void processRequest(PortletRequest request, PortletResponse response,
String defaultPage, String requestType) throws PortletException,
IOException
{
Map strutsAttributes = _removeStrutsAttributes(request);
try {
super.processRequest(request, response, defaultPage, requestType);
} finally {
_setStrutsAttributes(request, strutsAttributes);
}
}
private Map _removeStrutsAttributes(PortletRequest req) {
Map strutsAttributes = new HashMap();
Enumeration enu = req.getAttributeNames();
while (enu.hasMoreElements()) {
String attributeName = (String)enu.nextElement();
if (attributeName.startsWith(_STRUTS_PACKAGE)) {
strutsAttributes.put(
attributeName, req.getAttribute(attributeName));
}
}
Iterator itr = strutsAttributes.keySet().iterator();
while (itr.hasNext()) {
String attributeName = (String)itr.next();
req.removeAttribute(attributeName);
}
ModuleConfig moduleConfig =
(ModuleConfig)getPortletContext().getAttribute(Globals.MODULE_KEY);
req.setAttribute(Globals.MODULE_KEY, moduleConfig);
return strutsAttributes;
}
private void _setStrutsAttributes(PortletRequest req, Map strutsAttributes) {
Iterator itr = strutsAttributes.entrySet().iterator();
while (itr.hasNext()) {
Map.Entry entry = (Map.Entry)itr.next();
String key = (String)entry.getKey();
Object value = entry.getValue();
req.setAttribute(key, value);
}
}
}
> Resources overewritten by portlet: need to be restored
> ------------------------------------------------------
>
> Key: PB-9
> URL: http://issues.apache.org/jira/browse/PB-9
> Project: Portals Bridges
> Type: Bug
> Components: struts
> Versions: 0.4
> Environment: JBoss 4.0.2 w/ Tomcat 5x; Liferay Portal 3.6.1; Struts 1.27; JDK 1.4.2_09; WinXP
> Reporter: James Schopp
> Assignee: Ate Douma
>
> Liferay uses Struts to layout the actual portal itself, and so has message resources stored in the request attributes under the Struts key Globals.MESSAGES_KEY. This gets overwritten by portlets using Struts Bridges, and causes problems later on (at leaast in Liferay) in portal rendering (since messages can longer be found).
> I have created a temporary fix in Liiferay by creating my own StrutsPortlet subclass that saves off the messages before processRequest runs, and restores them afterward. However, I believe this should actually be a part of the default StrutsPortlet provided with bridges, since it could/should really affect any portal framework (potentially).
> The code is VERY simple to implement. Here is the subclass that I created: it is obvious how to incorporate it into the base class:
> <code>
> package com.liferay.portal.apache.bridges;
> import java.io.IOException;
> import javax.portlet.PortletException;
> import javax.portlet.PortletRequest;
> import javax.portlet.PortletResponse;
> import javax.servlet.http.HttpServletRequest;
> import org.apache.portals.bridges.struts.StrutsPortlet;
> import org.apache.struts.Globals;
> /**
> * LiferayStrutsPortlet this portlet adds the additional functionality (over StrutsPortlet) to restore overwritten resources.
> * It works such that:
> * <ul>
> * <li>message resources that were in in the request BEFORE the call to processRequest are saved restored afterward such
> * as to avoid conflicts with resources used for the portal itself (and other struts portlets)</li>
> * </ul>
> *
> * @author James Schopp
> *
> */
> public class LiferayStrutsPortlet extends StrutsPortlet
> {
> protected void processRequest(PortletRequest request, PortletResponse response,
> String defaultPage, String requestType) throws PortletException,
> IOException
> {
> HttpServletRequest req = getHttpServletRequest(this, request, response);
> Object objMessages = req.getAttribute(Globals.MESSAGES_KEY);
>
> try {
> super.processRequest(request, response, defaultPage, requestType);
> } finally {
> req.setAttribute(Globals.MESSAGES_KEY, objMessages);
> }
> }
> }
> </code>
--
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: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Commented: (PB-9) Resources overewritten by portlet: need to be restored
Posted by "Ate Douma (JIRA)" <br...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/PB-9?page=comments#action_12330731 ]
Ate Douma commented on PB-9:
----------------------------
James,
Great to hear the Struts Bridge also is (almost) working on Liferay now.
I've also seen the http://support.liferay.com/browse/LEP-529 issue and will watch it for other possible issue which might come up ;-)
I think this particular problem isn't restricted to just the Globals.MESSAGES_KEY or specific to the Struts Bridge but a more general one.
First of all, I would expect other Struts attributes (like those defined in org.apache.struts.Globals) might get overwritten too.
Then, only caching the Globals.MESSAGES_KEY won't be enough.
But, *any* Portlet (or included Servlet) might cause these kind of problems, Struts (Bridge) based or not...
I think Liferay (as well as other Portals) should protect its own critical request attributes and not rely on "nice" behavior of Portlets to not modify them.
in Jetspeed we prefix our Portal attributes with "org.apache.jetspeed." for this reason.
As we don't use Struts (or any other common framework) on portal level, we don't have this problem.
To solve this "properly" for Liferay, I would suggest it to copy all its portal request attributes (which are not yet prefixed with "com.liferay.portal.") with something
like "com.liferay.portal.saved_<attribute_name>" before invoking a portlet and restore them afterwards.
So, I hope this won't disappoint you, but I don't intend to implement your suggested workaround as it never would be fail prove.
Only protecting *all* attributes would be, and in my opinion, that should be the responsibility of the portal...
> Resources overewritten by portlet: need to be restored
> ------------------------------------------------------
>
> Key: PB-9
> URL: http://issues.apache.org/jira/browse/PB-9
> Project: Portals Bridges
> Type: Bug
> Components: struts
> Versions: 0.4
> Environment: JBoss 4.0.2 w/ Tomcat 5x; Liferay Portal 3.6.1; Struts 1.27; JDK 1.4.2_09; WinXP
> Reporter: James Schopp
>
> Liferay uses Struts to layout the actual portal itself, and so has message resources stored in the request attributes under the Struts key Globals.MESSAGES_KEY. This gets overwritten by portlets using Struts Bridges, and causes problems later on (at leaast in Liferay) in portal rendering (since messages can longer be found).
> I have created a temporary fix in Liiferay by creating my own StrutsPortlet subclass that saves off the messages before processRequest runs, and restores them afterward. However, I believe this should actually be a part of the default StrutsPortlet provided with bridges, since it could/should really affect any portal framework (potentially).
> The code is VERY simple to implement. Here is the subclass that I created: it is obvious how to incorporate it into the base class:
> <code>
> package com.liferay.portal.apache.bridges;
> import java.io.IOException;
> import javax.portlet.PortletException;
> import javax.portlet.PortletRequest;
> import javax.portlet.PortletResponse;
> import javax.servlet.http.HttpServletRequest;
> import org.apache.portals.bridges.struts.StrutsPortlet;
> import org.apache.struts.Globals;
> /**
> * LiferayStrutsPortlet this portlet adds the additional functionality (over StrutsPortlet) to restore overwritten resources.
> * It works such that:
> * <ul>
> * <li>message resources that were in in the request BEFORE the call to processRequest are saved restored afterward such
> * as to avoid conflicts with resources used for the portal itself (and other struts portlets)</li>
> * </ul>
> *
> * @author James Schopp
> *
> */
> public class LiferayStrutsPortlet extends StrutsPortlet
> {
> protected void processRequest(PortletRequest request, PortletResponse response,
> String defaultPage, String requestType) throws PortletException,
> IOException
> {
> HttpServletRequest req = getHttpServletRequest(this, request, response);
> Object objMessages = req.getAttribute(Globals.MESSAGES_KEY);
>
> try {
> super.processRequest(request, response, defaultPage, requestType);
> } finally {
> req.setAttribute(Globals.MESSAGES_KEY, objMessages);
> }
> }
> }
> </code>
--
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: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Resolved: (PB-9) Resources overewritten by portlet: need to be restored
Posted by "Ate Douma (JIRA)" <br...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/PB-9?page=all ]
Ate Douma resolved PB-9:
------------------------
Resolution: Won't Fix
Assign To: Ate Douma
> Resources overewritten by portlet: need to be restored
> ------------------------------------------------------
>
> Key: PB-9
> URL: http://issues.apache.org/jira/browse/PB-9
> Project: Portals Bridges
> Type: Bug
> Components: struts
> Versions: 0.4
> Environment: JBoss 4.0.2 w/ Tomcat 5x; Liferay Portal 3.6.1; Struts 1.27; JDK 1.4.2_09; WinXP
> Reporter: James Schopp
> Assignee: Ate Douma
>
> Liferay uses Struts to layout the actual portal itself, and so has message resources stored in the request attributes under the Struts key Globals.MESSAGES_KEY. This gets overwritten by portlets using Struts Bridges, and causes problems later on (at leaast in Liferay) in portal rendering (since messages can longer be found).
> I have created a temporary fix in Liiferay by creating my own StrutsPortlet subclass that saves off the messages before processRequest runs, and restores them afterward. However, I believe this should actually be a part of the default StrutsPortlet provided with bridges, since it could/should really affect any portal framework (potentially).
> The code is VERY simple to implement. Here is the subclass that I created: it is obvious how to incorporate it into the base class:
> <code>
> package com.liferay.portal.apache.bridges;
> import java.io.IOException;
> import javax.portlet.PortletException;
> import javax.portlet.PortletRequest;
> import javax.portlet.PortletResponse;
> import javax.servlet.http.HttpServletRequest;
> import org.apache.portals.bridges.struts.StrutsPortlet;
> import org.apache.struts.Globals;
> /**
> * LiferayStrutsPortlet this portlet adds the additional functionality (over StrutsPortlet) to restore overwritten resources.
> * It works such that:
> * <ul>
> * <li>message resources that were in in the request BEFORE the call to processRequest are saved restored afterward such
> * as to avoid conflicts with resources used for the portal itself (and other struts portlets)</li>
> * </ul>
> *
> * @author James Schopp
> *
> */
> public class LiferayStrutsPortlet extends StrutsPortlet
> {
> protected void processRequest(PortletRequest request, PortletResponse response,
> String defaultPage, String requestType) throws PortletException,
> IOException
> {
> HttpServletRequest req = getHttpServletRequest(this, request, response);
> Object objMessages = req.getAttribute(Globals.MESSAGES_KEY);
>
> try {
> super.processRequest(request, response, defaultPage, requestType);
> } finally {
> req.setAttribute(Globals.MESSAGES_KEY, objMessages);
> }
> }
> }
> </code>
--
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: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org