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