portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Woonsan Ko (JIRA)" <jetspeed-...@portals.apache.org>
Subject [jira] Issue Comment Edited: (JS2-974) After pluto-2 integration, JSP decorators does not work
Date Thu, 23 Apr 2009 13:45:30 GMT

    [ https://issues.apache.org/jira/browse/JS2-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701931#action_12701931
] 

Woonsan Ko edited comment on JS2-974 at 4/23/09 6:45 AM:
---------------------------------------------------------

This problem happens again after reopening and fixing again for PLUTO-554.
Initially, I tested the problem (importing other jsp page) in a pluto deployment to validate
the fix for PLUTO-554.
It worked fine with multiple nested jsp imports.
So, the problem was localized into JS-2.
And, I did some debugging and I found that this happened only for local layout portlet.

When a portlet tries to include something initially, getRequest() is as same as initialRequest.
And, when a servlet dispatched by the portlet is being executed, then getRequest() from the
servlet-side is not as same as initialRequest. 
It's because Tomcat create another request object for the included servlet.
And, the important thing is that this happens only when the servlet is really dispatched via
servlet request dispatcher (ApplicationDispatcher) by Tomcat.

However, the local portlets is not invoked via servlet request dispatcher. LocalPortletInvoker
invokes portlet wrapper methods directly. That's why this problem happens again.

We cannot solve this problem by wrapping the request again.

Therefore, I think the only option is to force local portlets to use portletRequest.getRequestDispatcher()
only, disallowing to use servletContext.getRequestDispatcher().

WDYT?

      was (Author: woon_san):
    This problem happens again after reopening and fixing again for PLUTO-554.
Initially, I tested the problem (importing other jsp page) in a pluto deployment to validate
the fix for PLUTO-554.
It worked fine with multiple nested jsp imports.
So, the problem was localized into JS-2.
And, I did some debugging and I found that this happened only for local layout portlet.

When a portlet tries to include something initially, getRequest() is as same as initialRequest.
And, when a servlet dispatched by the portlet is being executed, then getRequest() from the
servlet-side is not as same as initialRequest. 
It's because Tomcat create another request object for the included servlet.
And, the important thing is that this happens only when the servlet is really dispatched via
servlet request dispatcher (ApplicationDispatcher) by Tomcat.

However, the local portlets is not invoked via servlet request dispatcher. LocalPortletInvoker
invokes portlet wrapper methods directly. That's why this problem happens again.

In my opinion, if we wrap the request for local portlet, then it will work fine.


  
> After pluto-2 integration, JSP decorators does not work
> -------------------------------------------------------
>
>                 Key: JS2-974
>                 URL: https://issues.apache.org/jira/browse/JS2-974
>             Project: Jetspeed 2
>          Issue Type: Bug
>          Components: Aggregation
>    Affects Versions: 2.2.0
>            Reporter: Woonsan Ko
>            Assignee: Woonsan Ko
>
> I found errors showing an infinite loop and stackOverFlow error, printing many lines
containing:
>     
>     ...
>     org.apache.catalina.core.ApplicationHttpRequest.getAttribute....
>     org.apache.catalina.core.ApplicationHttpRequest.getAttribute....
>     ...
>     org.apache.catalina.core.ApplicationHttpRequest.getAttribute....
>     ...
>     org.apache.pluto.container.impl.HttpServletPortletRequestWrapper.getAttribute...
>     ...
> I've just googled and found an existing issue: https://issues.apache.org/bugzilla/show_bug.cgi?id=47017
> In the above issue, the problem was diagnosed as, "Something somewhere called setRequest()
on the wrapped request and passed in the same wrapped request setting up the infinite loop."
> I have tried to test locally by modifying HttpServletPortletRequestWrapper, but I have
no clue yet.
> I also suspect that this problem can occur for local portlet.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message