This is option two, which is more flexible but potentially will fall victim to misunderstanding in certain cases:

@ApplicationScoped
public class HelloWorldService {

    @Inject
    private Event<ServerMsg> serverMessage;

    @Conversational
    public void receive(@Observes ClientMsg msg) {
        ServerMsg outgoing = new ServerMsg(msg.getMessage());
        serverMessage.fire(outgoing);
    }
}

The @Conversational annotation envelops the call in a CDI interceptor and wraps the invocation.  The configurator also knows in this case to activate the contexts for inbound messages from the browser. So the conversation begins and ends around the method. The advantage of this is that the syntax is simple, but that ANY message you fire from within that method will automagically become conversational. Which means, to get around it -- if you wanted to do both global and conversational within the same method -- you couldn't. You'd need two observer methods for ClientMsg, one conversation and one not, that somehow coordinate their work.


On Apr 10, 2011, at 7:56 PM, Mike Brock wrote:

This is my proposal for creating secure, typesafe conversations using CDI Events.  As opposed to using an external API, what if we use an interface like so:

package org.muhtest.server;

import org.jboss.errai.cdi.server.ConversationalEvent;
import org.muhtest.client.ClientMsg;
import org.muhtest.client.ServerMsg;

import javax.enterprise.context.ApplicationScoped;
import javax.enterprise.event.Observes;

@ApplicationScoped
public class HelloWorldService {
    public void receive(@Observes ConversationalEvent<ClientMsg, ServerMsg> event) {
        /**
         * Get the incoming event.
         */
        ClientMsg incoming = event.getEvent();

        /**
         * Build the outgoing event.
         */
        ServerMsg outgoing = new ServerMsg(incoming.getMessage());

        /**
         * Return to sender!
         */
        event.fire(outgoing);
    }
}

Basically we create a a standard ConversationalEvent interface that is parameterized with the incoming type, and the outgoing type. The EventDispatcher can then simply wrap the incoming event before firing it into the BeanManager, and this way, the event payload itself contains a pre-loaded firing mechanism to fire an outgoing message back to the client. 

I have already hacked a simple prototype on top of Heiko and Fillip's CDI integration code. 

I added Dan Allen to this message, as I thought he might have something interesting to say, since he worked on this aspect of the CDI spec. 

Thoughts?

Mike.