I am just wildly guessing her, because I have not yet used the Trinidad dialog
framework.
I think the CONVERSATION_ID_SESSION_PARAMETER refers to the _Seam_
conversation id.
You can configure that parameter name in your component.xml, in Seam 1.2.1 it
worked this way (no idea if it changed):
<core:manager conversation-timeout="120000"
concurrent-request-timeout="500"
conversation-id-parameter="cid"
conversation-is-long-running-parameter="clr"/>
Maybe this helps.
Hi,
I was looking into
http://wiki.apache.org/myfaces/Trinidad_And_Seam
and found that with Seam 2.0RC1 thingshave changed so far as that
the described workaround regarding theintegration of Trinidad's dialog
framework with Seam does not seem to workanymore.
But it could also be that somethingis not working properly on my side.
More precisley speaking, I found thatthe critical location in that workaround
is
privatevoidrestoreConversation(Context context) {
if(context.isSet(CONVERSATION_ID_SESSION_PARAMETER)){
String convId =
context.get(CONVERSATION_ID_SESSION_PARAMETER).toString();
System.out.println("==================restoreConversation
attempt with convId:"+convId);
ConversationPropagation.instance().restoreConversationId(createParameterMapForConversationRestore(convId));
context.remove(CONVERSATION_ID_SESSION_PARAMETER);
} else{//TODOproblem is that it never enters above restoration
but always has unsetcontext!!
System.out.println("==================no
restoreConversation attempt due to unset context!");
}
}
So what happens is that this methodis always branching into the else part so no
restoration takes place.
The CONVERSATION_ID_SESSION_PARAMETRis"cid" but I am not sure if this is still
really the valid magicalconstant for Trinidad's conversation id
which would explain why it's never there.
Any ideas? Is "cid" stillcorrect? I did not know where to look.. ;<(
Many thanks,
Wolfgang.
