A keyword and answer session

jboss seam session vs conversation: A Session is a standard Servlet concept – a collection of attributes that the server maintains while a user is active on web application. Applications leverage it heavily to store server-side the current state of the user – such as the contents of his or her shopping basket. There are other collections – for example, those associated with a single HTTP request. Seam takes this several steps further. Each of these original collections has it’s place in Seam as a Context, along with several new ones that Seam uses and provides. This sounds onerous, but in Seam you no longer have to know that the attribute you want is stored in the session, you can instead just ‘inject’ the attribute, and Seam will find it for you from any of the contexts it supports.

One of these contexts is the Seam conversation context. It doesn’t last as long as a the user’s Session, by default timing out after 5 minutes of inactivity, but it’s lifetime is entirely managed by the Seam framework, avoiding the messiness that comes with losing all the user-specific state you left in an expired Session when a user resumes activity.

Naturally just as an application may manage multiple concurrent user sessions, Seam lets you have multiple conversations per user session. A widely used analogy is that of a workspace; in our case we have one workspace for each document that our users may be editing.

I can only speak about JSF, as Seam supports several view layers; but here Seam really shines. In JSF plain, managed beans have to be declared in faces-config.xml. In Seam, a custom EL resolver evaluates EL statements (#{}) and dynamically identifies from the Seam contexts which bean to use. This process is similar to injection, and so Seam is able to look up any bean stored in any of it’s contexts, or even create on the fly an instance of properly annotated java class. So – no more faces-config.XML.

With the custom EL resolver and a heirarchical context search, Seam allows you to write beans and pages that work in the context of a particular workspace (conversation). When a page is rendered, Seam knows what conversation that page is being rendered in, and so it can dynamically pull the correct bean instances from the correct conversation context instance.

Part of the state of a conversation is what page you are looking at in an application. Seam conversations can be used for a limited form of page flow. This is because not only can a user have multiple conversations per session, but conversations can also be nested. By creating a nested conversation, the parent conversation is frozen along with the view the user was last looking at while in that conversation. When a user causes the nested conversation to end, Seam can return the user to the parent conversation and also to the page they were on before the user entered into the scope of the nested conversation. Conversations can be arbitrarily nested, and attributes of the parent conversation are available to the nested conversations through injection and EL resolution. The process of searching contexts for attributes is known as the hierarchical context search in Seam.

Lastly, I should mention that there is always a Seam conversation in place. This differs from explicitly created ‘long running conversations’ in that it is temporary and lives only for the duration of postback + possible redirect. This temporary conversation is used by Seam to traffic JSF Faces Messages through a redirect. For example, say you have a page with a button, and when you click that button you trigger an error. But you want the specific error to be displayed on another page. The postback for the button could redirect the user to the error handling page, but in standard JSF you would lose the specific error message stored in the FacesMessages object. Seam keeps those messages in the conversation context so that it doesn’t matter what page renders the result of the user’s interaction – the messages will still be available. This is just one example where the conversations helps Seam smooth over JSF’s wrinkles.

no active conversation context: With the above knowledge, this exception should now be easy to understand. Take the example of a deep bookmark saved from a Seam web application. Let’s say that this page was bookmarked from the a ticket reservation system, and because of this it relies on beans that exist only while tickets are temporarily reserved for purchasing. These beans could reasonably be marked @Conversational or otherwise explicitly scoped to the Conversation contexts as even just 5 minutes later, the tickets would no longer reserved for purchasing. (In this case the 5 minute expiry of the conversation is tied to the business process, however all conversations in Seam expire). If the user navigates to this deep bookmark after the conversation has expired, then this exception will be thrown.

You have a couple of options to work around this exception:
1) Increase the conversation timeout in components.xml, or more likely
2) Trap the exception in pages.xml and redirect the user to a page that will let them restore or restart their activity.

(And for the record, yes, the keywords that caused me to write these articles were listed as incoming searches using google analytics )