2 Replies Latest reply on Jun 10, 2013 1:02 PM by John DeStefano

    EventConversationContext question

    John DeStefano Apprentice

      Hi,

       

      Through the EventConversationContext, while in a conversational event, is it possible to change the context in such a way as to fire a response event back to a different client if you know that other client's session id? I looked at the context code, spefically the activate method, but am unsure if that will work. It looks as if you provide a different queue session that further event fired while in that context could be routed to other queues, thus other users. The reason I ask, is I'm working on a chat feature in an application, where a user can chat with one other user. I track the user session id's. I understand this would be possible using the Message api, but was interested in the possiblity of using CDI Events?

       

      Thanks

        • 1. Re: EventConversationContext question
          Jonathan Fuerth Master

          Hi John,

           

          This is something we may be able to look at when updating Errai to CDI 1.1. Right now, we cannot manipulate Weld's context information without touching non-public (unstable, unsupported) APIs. This is the reason we don't support use of the AsyncDispatcher in conjunction with server-side Errai CDI: everything has to be done on the thread that originated the request, so Weld's context information is correct.

           

          My understanding is that this context shuffling was made more explicit in CDI 1.1, but I have not yet dug into the new spec to see if the new APIs would allow the behaviour you're asking about.

           

          As you say, acheiving the same functionality with the MessageBuilder from ErraiBus is simple. Just create a unique subject name for each private conversation, and the bus's routing logic will take care of sending the correct messages to the correct clients. No need to dig into QueueID and SessionID stuff at all!

           

          The fundamental difference between the two approaches is that CDI is designed to be declarative and statically typed (even qualifiers must be known at compile time), whereas the bus is a programmatic API that allows you to create and destroy arbitrary subject names at runtime. In a use case such as yours, where not all users can be known at compile time, I think the dynamic/programmatic approach is the better fit–even if you can manage to figure out how to route the CDI events to specific clients.

           

          Hope that helps,

          Jonathan

          • 2. Re: EventConversationContext question
            John DeStefano Apprentice

            Thanks, that answers my question.