Hi! > Class Conversation uses a thread-local variable to store the "current > conversation". Thread-locals are pretty tricky to manage in a container > environment; they need to be cleared at the end of each request as the > same thread will be reused by the container. > > Would storing this value in request scope be acceptable instead? > No, this is not possible.
For each bean requested from the conversation scope a new conversation will be started. You can put multiple beans into the same conversation by adding the orchestra:conversationName="" attribute to the spring bean configuration. This means you can have multiple conversations in parallel. To make things a little bit more complicated, you can have the same conversations per conversationContext. This makes it possible to have multiple windows. The scope hierarchy is: application->session->conversationContext->conversation starting with session they are 1:n. The conversation object is like the http session just a container for the conversation scoped beans. Now, to get access to this scope we have the Conversation.getCurrentInstance() which works only from within a conversation scoped bean. This method returns the "conversation container" the current bean lives in. To make this work, we use Spring AOP (see org.apache.myfaces.orchestra.conversation.CurrentConversationAdvice) this advice triggers for every method (public methods) call to the conversation scoped bean - in other words: It is a proxy which transparently wraps your bean and just maintains the thread-local. (Have a look at SpringConversationScope.getBean:137 to see what happens when a new bean is going to be created) As you can see, in the finally block we set it to the previous value - which is null for the topmost call. What we might do is to use reflection to see if there is a ThreadLocal.remove() method and call this in Conversation.setCurrentInstance() in case of conversation==null. If this is required. Ciao, Mario
