[ 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to