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