&quot;app4you(a)yahoo.com&quot; wrote : | -> SESSION scope is never a good implementation unless you have a very good reason to go for, Yes, you shouldn't put data that doesn't need to be session scoped into the session. But if your spec says that you need session scope views then... anonymous wrote : neither a very long running conversation timeout or even set it to the same time-out as the HTTP session time out. Standard is 30 minutes, or at least most of my apps. Sorry, I can't parse this. anonymous wrote : ->. Imagine that your application has tab and tree UI components exposed all time and setting the conversation timeout greater than the HTTP session time out or unlimited, aren't you asking for trouble? You will have a whole bunch of runaway conversations running behind the scene and waiting to be closed by the their conversation timers, assume that the user did not click on the DONE or CLOSE button to close the forms' conversations properly. I can't see why. anonymous wrote : anonymous wrote : Or are you after flexibility - giving different conversations different timeouts (you can currently do this programmatically, but not through xml/annotations) | | -> Who would you go about that? And would that manually setting be scattered all over the place, for each component that is? You could have a property on the @Begin annotation and on the pages.xml begin-conversation element that takes either a integer or injects an integer using EL. Further, there is undocumented support for conversations which use natural ids - you could set the timeout for such a conversation. anonymous wrote : What we need is the ability to control the conversation time-out to rely on the HTTP session timeout Something like this would perhaps help (but you would still get conversations timing out before the session if they hadn't been "touched" recently). components.xml | <core:manager concurrent-request-timeout="500" | conversation-timeout="#{session.timeout}" conversation-id-parameter="cid" | conversation-is-long-running-parameter="clr" /> | anonymous wrote : or a way to disable the conversation timeout but not by means of "never timed out conversations" Surely this is an oxymoron - you want to have conversations that don't timeout but don't never timeout. You need to explain this one better ;) If you are saying you want to clean up the conversations associated with a user when their session times out, then this is current behaviour. anonymous wrote : Just try to put a complex UI application that has a lot of business components with tree+tab interfaces and see how sufficient the application conversation stack can be. Please make sure that "the application data entry form has to be in the edit mode all the time unless the user want to close the form by clicking on the DONE, CLOSE or whatever... button to get back to the search result page". | Yes, if you want to hold open a view as long as the sesion is active, then you have to use the session to hold the data. A shorter-lived scope won't ever cut it here! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038120#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...