Oh, and a big thank you for the rest of the Seam functionality working really, really well. Nice integration overall.

Edwin Jaufmann

If one looks at a portal as a collection of independent applications that may react to changes in state in any of the collected applications (which is what the portal standard establishes, since, when one portlet executes a request, all portlets that are displayed receive a signal to redisplay once the request completes) all portlets participating in the same conversation could share state.

So, if one portlet did a search, the results of which might be used by other portlets to display specific drill down aspects of the results (perspectives), this would be accomplished by all participating portlets sharing a conversation. Extend that to multiple search results being extant, each in its own conversation, now when the user switches conversations, all portlets sharing the current conversation would also switch state when the redisplayed.

A greater Use Case question is whether the purpose of the bridge is to allow seam to function in a portal the same way it would function in a stand alone application. If that is true, the bridge would allow all portlets to share the contexts in the same way stand alone applications might share the same contexts. So right now, rather than a Seam Session being a single context attached to the user identity, there is now N Seam Sessions one attached to the user identity within a portlet. The stove piping of Sessions changes the character of Seam. If I had multiple windows in a stand alone seam application all of which were referring to the current conversation, when I switch conversations, all states switch in all particpating windows.

Right now, I am writing components to share information within the Application Context using user identity, but that is exactly what the Session context in seam is meant to do and I really don't have true conversations available, as having a conversation within a single portlet has relatively low functional value.

The Use case supporting Portals and Portlets is to give the visual aspects of applications the same OO flexible that application object currently have available. I can take a portlet and place it somewhere within a Portal (even an end user can move them around in some Portals) and they should function in coordination with all other Portlets. The power of having the same Seam Contexts working in the same way as they do in non-Portal environments would give Portal application development in Seam an edge over anything out there, in my view. It would create true drop in applications (Portlets) for Portals.

I hope this is helpful. Again, if I'm out in left field, I'm open to redirection and encourage the feedback.

Thanks.