I sort of do too.  Christian and Dan seem to like @Conversational.  So let me play devil's advocate with myself.

I think there's some merit to how this works. And it's not necessarily as "magical" as it appears.

If you think about the way in which ErraCDI and Weld federate, then what does @Conversational mean?  

What it means is that when this method is dispatched, the federation visibility should be limited to the node that first fired the method. 

From Weld's perspective, it has absolutely no effect on how things "should world".  It does have an effect on how the remote CDI container and the local CDI container inter-operate with each other. So this is forming a visibility rule linked to the dispatch scope of a method.  Is this really a bad way of going about it?

The absolute only pitfal is that you can't broadcast from within that method. And is that even a bad limitation? I'm not sure.

Thoughts?

Mike.

On Apr 21, 2011, at 7:41 AM, Peter Muir wrote:

I prefer your first suggestion

On 11 Apr 2011, at 04:02, Mike Brock wrote:

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.

_______________________________________________
errai-users mailing list
errai-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-users

_______________________________________________
errai-users mailing list
errai-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-users