This leads to another question: why do we need to pass the "?cid=1" in the URL? since the Conversation is stored in the HttpSession, the Weld should be able to restore the LRC without cid request parameter? could anyone please explain this?

If HttpSession is timeout, it didn't trigger @PreDestroy callbacks of SessionScoped and ConversationScoped beans, is this a bug too or defined in the spec.?

Actually when HttpSession timeout, it does call @PreDestroy method of SessionScoped beans, but not @ConversationScoped beans.

And I guess it should be split into 2 problems:

1, When HttpSession timeout, it should call @PreDestroy methods on @ConversationScoped beans (see org.jboss.weld.servlet.ServletLifecycle.mockedSessionTermination)

2, acquire conversation ID from request parameter cause the exception, for example: when action method returned after conversation.begin() method, the url sent to the browser has been appened with  "?cid=1" (see org.jboss.weld.jsf.ConversationAwareViewHandler.getActionURL), when the request sent back to the server after HttpSession timeout, the ServletLifecycle try to restore the conversation (see org.jboss.weld.servlet.ServletLifecycle.restoreConversationContext), and the cid doesn't exist in the newly created HttpSession, thus it throws NonexistentConversationException (see org.jboss.weld.conversation.setupConversation).

I'm using the Weld1.1.0-SNAPSHOT, and I found that in the ServletLifeCycle it does create SessionBeanStore couple times for each request come in, this could be a performance impact (if the page contains some js/css/imgs in the same context, when browser retrieve those resources, it actually trigger session created/destroy, request begin/destroy events)

Could someone please look into this problem?

I have created the JIRA ticket: WELD-636