Re: Problem with Pluto Portlets and the Sun JSF Portlets

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?
>
>  
>