Re: Wrong view being resolved in Pluto?

Nevermind. Have conversation on uPortal-user mailing list going on about 
it, and doesn't seem to be a Pluto issue.

Gary


On 11/5/10 3:29 PM, Gary Weaver wrote:
> Hello!
>
> I need someone with some historical knowledge of Pluto to help me out
> with this one.
>
> For some reason, portlets that we have using portlet-mvc 2.0.1 or
> spring-webmvc-portlet 2.5.6 using uPortal 2.5.3.2 with Pluto 1.0.1 have
> shown the following behavior:
>
> It seems that when the handleRenderRequestInternal method completes
> quickly, then the following happens (this example log fragment was from
> a portlet using spring-webmvc-portlet 2.5.6):
>
> [CODE]DEBUG [Thread-366] Nov/04 10:57:16,917
> portlet.DispatcherPortlet.[] - DispatcherPortlet with name 'fooportlet'
> received render request
> DEBUG [Thread-366] Nov/04 10:57:16,917 portlet.DispatcherPortlet.[] -
> Bound render request context to thread:
> org.apache.pluto.core.impl.RenderRequestImpl@7f556a0e
> DEBUG [Thread-366] Nov/04 10:57:16,917 portlet.DispatcherPortlet.[] -
> Testing handler map
> [org.springframework.web.portlet.handler.PortletModeHandlerMapping@6703d837]
> in DispatcherPortlet with name 'fooportlet'
> DEBUG [Thread-366] Nov/04 10:57:16,918
> handler.PortletModeHandlerMapping.[] - Key [view] ->  handler
> [edu.acme.fooportlet.controller.FooPortletController@957ba31]
> DEBUG [Thread-366] Nov/04 10:57:16,918 portlet.DispatcherPortlet.[] -
> Testing handler adapter
> [org.springframework.web.portlet.mvc.SimpleControllerHandlerAdapter@2d6837b7]
> DEBUG [Thread-366] Nov/04 10:57:16,918
> controller.FooPortletController.[] - Request for fooportlet
> DEBUG [Thread-366] Nov/04 10:57:16,918
> controller.FooPortletController.[] - Got feed for 'http://acme.edu/feed'
> containing 10 entries.
> DEBUG [Thread-366] Nov/04 10:57:16,918 portlet.DispatcherPortlet.[] -
> Setting portlet response content type to view-determined type
> [text/html;charset=ISO-8859-1]
> DEBUG [Thread-366] Nov/04 10:57:16,919 view.JstlView.[] - Added model
> object 'somemodel' of type [java.util.RandomAccessSubList] to request in
> view with name 'view'
> DEBUG [Thread-366] Nov/04 10:57:16,919 view.JstlView.[] - Added model
> object 'anothermodel' of type [java.util.RandomAccessSubList] to request
> in view with name 'view'
> DEBUG [Thread-366] Nov/04 10:57:16,920 view.JstlView.[] - Including
> resource [/WEB-INF/jsp/view.jsp] in InternalResourceView 'view'
> DEBUG [Thread-366] Nov/04 10:57:16,920 servlet.JspServlet.[] - JspEngine
> -->  /barportlet/*
> DEBUG [Thread-366] Nov/04 10:57:16,920 servlet.JspServlet.[] -
> ServletPath: /barportlet
> DEBUG [Thread-366] Nov/04 10:57:16,920 servlet.JspServlet.[]
> -              PathInfo: /*
> DEBUG [Thread-366] Nov/04 10:57:16,920 servlet.JspServlet.[]
> -              RealPath: /path/to/tomcat/webapps/fooportlet/barportlet/*
> DEBUG [Thread-366] Nov/04 10:57:16,921 servlet.JspServlet.[] -
> RequestURI: /barportlet/barportlet/*
> DEBUG [Thread-366] Nov/04 10:57:16,921 servlet.JspServlet.[] -
> QueryString: null
> DEBUG [Thread-366] Nov/04 10:57:16,921 servlet.JspServlet.[] -
> Request Params:
> DEBUG [Thread-366] Nov/04 10:57:16,921 portlet.DispatcherPortlet.[] -
> Cleared thread-bound render request context:
> org.apache.pluto.core.impl.RenderRequestImpl@7f556a0e
> DEBUG [Thread-366] Nov/04 10:57:16,921 portlet.DispatcherPortlet.[] -
> Successfully completed request[/CODE]
>
> In this example FooPortlet is the portlet being rendered, but for some
> reason you can see that JspServlet is mixing some stuff up and using the
> BarPortlet's view.
>
> We didn't notice this until I made changes to the controller code within
> the FooPortlet so that the handleRenderRequestInternal method returned
> very quickly.
>
> I was able to remedy this by adding a Thread.sleep(800) to the end of
> the handleRenderRequestInternal method, but then noticed (as we had
> before) that this issue was still occurring intermittently in other
> portlets (specifically I noticed another one that is using portlet-mvc
> 2.0.1).
>
> If this was an issue in Pluto at some point, perhaps it was fixed long
> ago. If anyone remembers it, could you point me to a Jira ticket or any
> related documentation? I'm having a hard time finding anything for it.
> Or maybe someone could provide the right class and possibly the method
> that might be problematic, and maybe I could just patch pluto 1.0.1. I
> don't think later versions of Pluto work with uPortal 2.5.3.2, and we
> don't have the ability to upgrade at the moment, so anything you can
> share about this would help. I've grepped through the code myself, but I
> think I'd probably make progress faster if someone could help.
>
> Thanks!
>
> Gary