1:56 a.m.
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.
5:02 a.m.
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.
1:23 p.m.
Adding David Allen, who Mike meant, not Dan.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-users
1:41 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-users
7:22 p.m.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/errai-users
_______________________________________________
errai-users mailing list
errai-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-users
4818
days inactive
4829
days old
4 comments
2 participants
participants (2)
-
Mike Brock -
Peter Muir