Mailing-List: contact jetspeed-dev-help@portals.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jetspeed Developers List" <jetspeed-dev@portals.apache.org>
Message-ID: <1956012269.1240494330480.JavaMail.jira@brutus>
Date: Thu, 23 Apr 2009 06:45:30 -0700 (PDT)
From: "Woonsan Ko (JIRA)" <jetspeed-dev@portals.apache.org>
To: jetspeed-dev@portals.apache.org
Subject: [jira] Issue Comment Edited: (JS2-974) After pluto-2 integration,
 JSP decorators does not work
In-Reply-To: <182842832.1240336127534.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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