Re: Problem with Pluto Portlets and the Sun JSF Portlets

Just realized you attached the .java file

So the portletConfig comes from line 387:
        Map requestMap = context.getExternalContext().getRequestMap();
        PortletConfig portletConfig = 
(PortletConfig)requestMap.get("javax.portlet.PortletConfig");

I'm wondering if that is expected as a request attribute and if so what 
is supposed to set it? I do see in PLT.16.3.2 of the spec that 
"javax.portlet.config" is supposed to be set as an attribute (by the 
container) containing the PortletConfig when dispatching to or including 
a servlet/jsp during rendering but there is no dispatch or include in 
your stack trace and they would be using the wrong key.

So the question is what does the 'requestMap' represent and how does it 
get populated?

-Eric


Eric Dalquist wrote:
> portletConfig would have to be null to get a NPE on that line. .equals 
> should always be able to handle null as an argument so that wouldn't 
> cause the problem.
>
> I guess the next step is to figure out how portletConfig is supposed 
> to get set and why it isn't.
>
> -Eric
>
> Domazlicky, Eric wrote:
>>
>> Seems to be this line:
>>
>>  
>>
>> if("true".equals(portletConfig.getInitParameter(BridgeConstants.CLEARING_STATE_ENABLED)) 
>> )
>>
>>  
>>
>> portletConfig is NULL? Or maybe getInitParameter is returning NULL 
>> (I'm fairly certain this particular init param doesn't exist)? I'm 
>> attaching the source file if you need to do further analysis.
>>
>>  
>>
>> *From:* Eric Dalquist [mailto:[email protected]]
>> *Sent:* Tuesday, August 12, 2008 10:14 AM
>> *To:* [email protected]
>> *Subject:* Re: Problem with Pluto Portlets and the Sun JSF Portlets
>>
>>  
>>
>> It would be interesting to see what LifecycleImpl.java:353 is trying 
>> to do. Do you have a pointer to the source?
>>
>> -Eric
>>
>> Domazlicky, Eric wrote:
>>
>> Ok here is the latest on the issue. I resolved the last error to be a 
>> missing library. However now I am now getting this error:
>>
>>  
>>
>> Aug 12, 2008 7:58:49 AM 
>> org.apache.catalina.core.ApplicationDispatcher invoke
>>
>> SEVERE: Servlet.service() for servlet uPortalTest threw exception
>>
>> java.lang.NullPointerException
>>
>>                 at 
>> com.sun.faces.portlet.LifecycleImpl.clearState(LifecycleImpl.java:353)
>>
>>                 at 
>> com.sun.faces.portlet.LifecycleImpl.restore(LifecycleImpl.java:380)
>>
>>                 at 
>> com.sun.faces.portlet.LifecycleImpl.render(LifecycleImpl.java:231)
>>
>>                 at 
>> org.apache.portals.bridges.jsf.FacesPortlet.process(FacesPortlet.java:517)
>>
>>                 at 
>> org.apache.portals.bridges.jsf.FacesPortlet.doView(FacesPortlet.java:323)
>>
>>                 at 
>> javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
>>
>>                 at 
>> javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
>>
>>                 at 
>> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208)
>>
>>                 at 
>> org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139)
>>
>>                 at 
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
>>
>>                 at 
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>>
>>                 at 
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
>>
>>                 at 
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>>
>>                 at 
>> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:691)
>>
>>                 at 
>> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:594)
>>
>>                 at 
>> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
>>
>>                 at 
>> org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167)
>>
>>                 at 
>> org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101)
>>
>>                 at 
>> org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173)
>>
>>                 at 
>> org.jasig.portal.channels.portlet.SpringPortletChannelImpl.render(SpringPortletChannelImpl.java:480)
>>
>>                 at 
>> org.jasig.portal.channels.portlet.CSpringPortletAdaptor.renderCharacters(CSpringPortletAdaptor.java:186)
>>
>>                 at 
>> org.jasig.portal.ChannelRenderer$Worker.execute(ChannelRenderer.java:545)
>>
>>                 at 
>> org.jasig.portal.utils.threading.BaseTask.run(BaseTask.java:27)
>>
>>                 at 
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
>>
>>                 at 
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>>
>>                 at 
>> java.util.concurrent.FutureTask.run(FutureTask.java:138)
>>
>>                 at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
>>
>>                 at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
>>
>>                 at java.lang.Thread.run(Thread.java:619)
>>
>>  
>>
>>  
>>
>> This is what leads me to the conclusion that Apache Portlet Bridge 
>> and the Sun JSF Implementation just don't get along.  Any other ideas?
>>
>>  
>>
>> *From:* Eric Dalquist [mailto:[email protected]]
>> *Sent:* Wednesday, August 06, 2008 5:33 PM
>> *To:* [email protected] 
>> <mailto:[email protected]>
>> *Subject:* Re: Problem with Pluto Portlets and the Sun JSF Portlets
>>
>>  
>>
>> That may be a uPortal issue. One of the ways uPortal attempts to 
>> catch context loading problems is if content is written to the 
>> response object passed to Pluto when initializing a portlet window. 
>> The Faces bridge portlet must do this. The exception message should 
>> have included the content that was written out, perhaps you could 
>> include that in an email?
>>
>> -Eric
>>
>> Domazlicky, Eric wrote:
>>
>> Ok I realized my error I was using the wrong portlet-class from the 
>> Apache Portlet Bridge. I was using the GenericPortlet bridge when I 
>> should have been using the FacesPortlet bridge. My test Sun JSF 
>> Portlet now gets a totally different error that I suspect is uPortal 
>> related but maybe it's Pluto??
>>
>> "PortletLoadFailureException: Content was written to response during 
>> loading of portlet window..[].. Response Content: The requested 
>> resource /PlutoInvoker/TestPortlet is not available"
>>
>>  
>>
>>  
>>
>>  
>>
>> *From:* Michael Freedman [mailto:[email protected]]
>> *Sent:* Wednesday, August 06, 2008 4:09 PM
>> *To:* [email protected] 
>> <mailto:[email protected]>
>> *Subject:* Re: Problem with Pluto Portlets and the Sun JSF Portlets
>>
>>  
>>
>> If you are using the Bridge I pointed you at it also has the benefit 
>> of being Faces impl independent.  It will run with the Faces 1.2 
>> RI/Sun's Faces impl.  In fact I do most of my testing with a version 
>> of the RI.
>>     -Mike-
>>
>> Domazlicky, Eric wrote:
>>
>> Well the Apache Bridge seems to work. Unfortunately though NetBean's 
>> Visual Designer seems to be tied to Sun JSF's so that means you can't 
>> use the Designer to design a Portlet. I can get a pure MyFaces 
>> example portlet to work using the Apache JSF Bridge however so at 
>> least I can confirm that Faces can work under uPortal/PLUTO.
>>
>>  
>>
>>  
>>
>> *From:* Michael Freedman [mailto:[email protected]]
>> *Sent:* Wednesday, August 06, 2008 2:07 PM
>> *To:* [email protected] 
>> <mailto:[email protected]>
>> *Subject:* Re: Problem with Pluto Portlets and the Sun JSF Portlets
>>
>>  
>>
>> Definitely let me know if you run into any problems running your 
>> portlet with this bridge -- the JSR is supposed to define standard 
>> behavior for all bridges -- but obviously there is/was alot of 
>> existing prior art so I am interested in seeing if/what complications 
>> occur when users migrate so I can determine if its an issue related 
>> to specific implementation dependent function in the legacy bridge or 
>> the standard's definition needs expanding.
>>     -Mike-
>>
>> Domazlicky, Eric wrote:
>>
>> Thanks I'll give the Apache portlet-bridge a try and see what I can find.
>>
>>  
>>
>> *From:* Michael Freedman [mailto:[email protected]]
>> *Sent:* Wednesday, August 06, 2008 1:47 PM
>> *To:* [email protected] 
>> <mailto:[email protected]>
>> *Subject:* Re: Problem with Pluto Portlets and the Sun JSF Portlets
>>
>>  
>>
>> Request and Response wrapping is not supported in the Portlet 1.0 
>> (JSR 168) standard hence the use of a request wrapper by the Sun JSF 
>> bridge ( it is the Sun bridge, right?) is implementation dependent 
>> and can only be assumed to work in a Sun portlet container.  Instead, 
>> try the JSR 301 Bridge whose (early) Reference Implementation is on 
>> Apache (http://myfaces.apache.org/portlet-bridge/index.html).  I 
>> would suggest getting the sources and building yourself as the last 
>> release was posted coincident with the last early draft  earlier this 
>> year and things have progressed a bit since then.  (Though that 
>> binary release is also stable and fully functional for most uses).  
>> Note: this impl is intended to be portlet container independent.  It 
>> doesn't rely on wrapping.
>>
>> When you look at this Apache project you will notice there are two 
>> code lines.  The JSR is producing a spec and impl for both portlet 
>> 1.0 and portlet 2.0 with JSF 1.2.  Portlet 2.0 (JSR 286) does define 
>> wrapping, hence its the portlet 2.0 bridge version that wanted to use 
>> wrapping and hit the bug referenced by Craig. 
>>     -Mike-
>>
>> [email protected] <mailto:[email protected]> wrote:
>>
>> PLUTO-478 covers this issue. It was reported by Mike Freedman, spec 
>> lead of JSR-301, the JSF-Portlet Bridge.
>>
>>  
>>
>> Any fix to this issue should be done on the 1.1.x and 2.0-refactoring 
>> branch and the trunk.
>> /Craig
>>
>>  
>>
>>  
>>
>> [email protected] wrote: -----
>>
>>     To: [email protected]
>>     <mailto:[email protected]>
>>     From: [email protected] <mailto:[email protected]>
>>     Date: 08/05/2008 07:29PM
>>     Subject: Re: Problem with Pluto Portlets and the Sun JSF Portlets
>>
>>     > I had directed Eric over here from the uPortal lists.
>>     >
>>     > It appears that the JSF-Portlet library adds a response wrapper
>>     before
>>     > calling the request dispatcher. Does anyone here know if that is
>>     allowed
>>     > under JSR-168? There is no mention I can find in the spec or
>>     errata. I
>>     > do know in 286 explicit wrapper classes were added that mimic the
>>     > servlet API wrapper classes but that is all I've been able to find.
>>     > Should this be viewed as a Pluto bug or a JSF-Portlet bug?
>>     >
>>     > -Eric
>>
>>     I would expect the PortletRequestDispatcher.include() should
>>     accept any
>>     implementation of PortletRequest/Response, but that is probably not
>>     guaranteed by the spec.  Even if this is not a Pluto bug, I
>>     wonder if a
>>     simple fix might be to use a ThreadLocal to store the internal
>>     request/response objects when o.a.p.core.PortletServlet passes
>>     the request
>>     off to the portlet, rather than using wrapper classes.
>>
>>     Actually, as I look at the code, I wonder if
>>     PortletRequestDispatcherImpl.include should wrap the
>>     PortletRequest/Response objects in adapters that implement
>>     HttpServletRequest/Response rather than unwrap them to pull out the
>>     internal implementation.  That way, the client's wrapper classes
>>     could
>>     still function as expected.  I could put together a patch for
>>     this if you
>>     think it is a good idea.
>>
>>     -- Ben
>>
>>     P.S. - I'm replying to pluto-user, but I wonder if this is more
>>     appropriate for pluto-dev?
>>
>>  
>>