Lookup and activate/deactivate a conversation by ID

[pgmjsd]

In Seam 2 it was pretty easy to see how to activate a conversation given a conversation ID.   I've been looking through the CDI documentation for a similar feature, but I haven't found it yet.   Maybe it's only possible through a CDI extension, or (hopefully not) directly accessing Weld?   Sorry if I'm being thick here.

My use case is activating / deactivating a conversation in a Servlet.

[pgmjsd]

Some related information:

• http://stackoverflow.com/questions/11891035/how-to-retrieve-all-existing-long-running-conversations-in-weld
• http://www.andygibson.net/blog/tutorial/cdi-conversations-part-2/
  This approach uses a session-scoped bean to keep track of the conversation list. Other backing beans inject the current conversation and the session-scoped bean, adding the current conversation to the list just after starting the conversation.
• http://lucasterdev.altervista.org/wordpress/2012/01/09/workspace-management-with-cdi/
  This approach uses a Weld-specific API to do the same thing in a more 'framework-y' way.  It seems weird that you'd have to resort to Weld-specific org.jboss.weld.context in order to do something that Seam2 provided right out of the box.

[mkouba]

Just FYI in CDI 1.1 the conversation scope is active during all servlet requests, i.e. it's not tied to JSF anymore (see also 6.7.4. Conversation context lifecycle). However conversation workspace management is not part of the spec. I think Andy Gibson's approach seems quite reasonable. Although there are more elegant ways in CDI 1.1, e.g. having a decorator for built-in javax.enterprise.context.Conversation bean (see for example this TCK test: https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/decorators/builtin/conversati…).

[pgmjsd]

Hm... so "the conversation scope is active during all servlet requests" means that a particular conversation has been activated?   How would a servlet request identify the conversation?   Maybe you mean that the 'conversation manager' is active?

The decorator approach is interesting.   I'll have to check that out.

[pgmjsd]

Aha, CDI 1.1 provides a Servlet Filter that is responsible for activating the conversation based on the 'cid' request parameter.

[mkouba]

Well, not exactly. CDI 1.1 provides a special filter which may be mapped in web.xml so that the user is able to specify when is the conversation associaced (e.g. the user may register a custom filter before this filter to catch javax.enterprise.context.NonexistentConversationException). If you don't map this filter it's up to the container to determine the conversation at the beginning of the request before calling any service(), doFilter() and listeners (actually Weld is using a special ServletRequestListener). And yes, "cid" request parameter is used to identify the long-running conversation.

[pgmjsd]

I'm not that faimiliar with ServletRequestListener.   Is it called *before* any filter?

[mkouba]

Yes, have a look at its javadoc: http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequestListener.html