RE: MyFacesGenericPortlet behavior

[Stan Silvert <st...@jboss.com>]

Sven,

The problem with multiple JSF portlets on the same page is now fixed.  It was a bug with JBoss Portal failing to clear the request attributes when the request object is reused.  You will need to build from CVS as the fix didn't make it into the 2.0 final release.

Stan Silvert
JBoss, Inc.
ssilvert@jboss.com
callto://stansilvert

> -----Original Message-----
> From: Sven Schulz [mailto:schulz78@gmx.net]
> Sent: Friday, May 20, 2005 8:22 AM
> To: dev@myfaces.apache.org
> Cc: Stan Silvert
> Subject: Re: MyFacesGenericPortlet behavior
> 
> Hi Stan,
> 
> for the next months I probably won't have time to dive into this issue.
> However, I can contribute in another way. Despite of people telling that
> JBoss and MyFaces go along nicely my experience is different. I have
> isolated a number of issues (some of them already fixed locally):
> 
> (1) In AddResource the Request got from the ExternalContext is casted to
> HttpServletRequest. This is not what is intended by the Spec. Since only
> the
> context path is read after casting, the whole procedure can be replaced by
> using getRequestContextPath on the ExternalContext object directly. Since
> complex components like trees I wonder how these could ever be run (since
> a
> ClassCastException is thrown without the described fixes).
> 
> (2) Second invalid URLs are incoming to the encode methods of
> PortletExternalContextImpl. They look like "null/faces/...". I think this
> is
> a problem of JBoss, where one of the request methods (getRequestUrl, I
> think) is bogus. However since I don't have spare time to fix JBoss bugs I
> just repaired these URLs in PortletExternalContextImpl by replacing <null>
> with the correct prefix (which is the context path of the portlet
> request).
> 
> (3) If more than one portlet is displayed on a portal page things are
> getting really crazy. Nothing seems to work correctly. One issue I
> identified is that with multiple UIViewRoots on one page (from the
> different
> portlets) IDs are no loger unique. This is due to the createUniqueId
> implementation of UIViewRoot. I resolved this issue by registering my own
> Application implementation that intercepts UIViewRoot instantiations and
> injects a custom UIViewRoot implementation that diversifies component IDs
> with a additional UIViewRoot instance dependent identifier prefix.
> 
> But things are still not working now. Let's have a look at
> JspStateManagerImpl. In its saveSerializedView method the serialized view
> is
> stored in the request map under the key SERIALIZED_VIEW_REQUEST_ATTR.
> Having
> more than one view root on the page leads obviously to problems, since two
> different serialized views are stored under the same key. Diversifying the
> key with the view id of the UIViewRoot that is processed resolves this
> issue. The same kind of problem exists when storing the view into the
> (portlet) session in saveSerializedViewInServletSession. Here again
> diversification is necessary.
> 
> These are the issues I've discovered (and resolved) so far. But there is
> still a problem with more than one portlet on a page, which I think is
> related to state management too. The symptoms are that a parallel
> component
> hierarchy is built somewhere in the lifecycle that is written to the
> UIViewRoot. As a result there are always two hierarchies. But that's not
> all. When invoking actions in the different portlets of a page, it seems
> that sometimes the first, sometimes the second component hierarchy is
> rendered. I've debugged the code without success. Hope someone, perhaps
> the
> writer of the portlet bridge, has more insight and is able to resolve this
> issue.
> 
> Regards,
> Sven
> 
> --
> 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
> +++ GMX - die erste Adresse für Mail, Message, More +++