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