anonymous wrote : | This feature is not really "official" yet because it's not documented or demonstrated in any of the example apps. | It's actually part of the groundwork we needed to do for the upcoming JBossWS/Seam integration in 1.3.0. | Thank you Shane for the preview, I tried it out on Seam 1.2.1GA modifying my test case, unfortunately I did not find a way to keep alive a long running conversation using that stuff. Anyway, you did not release it officially and then I don't want to bother you with my results, if you are interested I will post you the details. anonymous wrote : | I don't know why you just spent so many words on explaining me the current behavior. | I know what the current behavior is. I know how it behaved in the test case you submitted. I'm happy with it. | Gavin, I spent all those words for two reasons: the former is to have a feedback from you on the way I use, understand (or misunderstand) the framework the latter is to understand if what I'm doing with Seam is reasonable and into the bounds of the Seam philosophy. But probably I'm not, or not completely and about this I would like to make you a(nother) question, or better, I try to tell you what I would reach: my application is really near to the Seam's workspace management, but this feature does not give me enough access to the conversation's list. I should wrap the conversationsList to render it as a tabbed view, unfortunately I cannot because I have to group sub-lists of conversations, indeed we have two levels of tabs, in the lower there are the actions, one per conversation, in the upper there is a logical grouping (tabs are grouped for functionality); then I should have a way to access and switch to a conversation both if the user asks for a particular functionality (the lower tab label) and if the user asks for another group of tabs (the upper tab label, switching to the 'opened' one in that group). In my app there's the same logical error you found in the test case: trying to switch to another conversation from an already long running, but this is quite simple to solve, I guess: I avoid to propagate the current conversation (the current tab viewed) when a user asks for a new service (from the menu, new open tab) or when refers to an already opened (selecting a tab label). I think this happens in conversationsList/conversationsStack stuff in the workspace management example. There's another little big problem with the conversationsList or conversationsStack: I tried to render it as an unordered list (what's behind the tabbed view) and the list provided changes everytime I switch from a conversation to another; this for a tabbed view of services is not reasonable. This is why I keep track of the conversations (storing the conversation identifier, passed as parameter to the related tab label link) to create the two levels tabbed view and use explicit conversation ids. Hope you have the time to read this and to give me advice about. Regards, Raffaele Camanzo View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4032570#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...