How to register a handler on the eventbus in Vert.x 3

[Rubin]

Hi all,

Short question: I'm experimenting with Vert.x 3, porting a small Vert.x
2 project; how does one register a java based verticle on the bus? In
Vert.x 2 I used to do this:

...
public void start() {
vertx.eventBus().registerHandler("foohandler",
new Handler<Message<JsonObject>>() { ...


But Vert.x 3 seems to not have "registerHandler". Could someone point me
in the right direction?

Kind regards,


Rubin.

[Julien Viet]

you should now do:

eventBus.consumer(“foohandler").handler(msg -> { … });

--
Julien Viet
www.julienviet.com

On 14 Nov 2014 at 17:58:45, Rubin (ru...@xs4all.nl) wrote:
> Hi all,
>
> Short question: I'm experimenting with Vert.x 3, porting a small Vert.x
> 2 project; how does one register a java based verticle on the bus? In
> Vert.x 2 I used to do this:
>
> ...
> public void start() {
> vertx.eventBus().registerHandler("foohandler",

> new Handler>() { ...

>
>
> But Vert.x 3 seems to not have "registerHandler". Could someone point me
> in the right direction?
>
> Kind regards,
>
>
> Rubin.
>

> --
> You received this message because you are subscribed to the Google Groups "vert.x" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

[Tim Fox]

On 14/11/14 17:38, Julien Viet wrote:
> you should now do:
>
> eventBus.consumer(“foohandler").handler(msg -> { … });
>
> --
> Julien Viet
> www.julienviet.com
>
>
> On 14 Nov 2014 at 17:58:45, Rubin (ru...@xs4all.nl) wrote:
>> Hi all,
>>
>> Short question: I'm experimenting with Vert.x 3, porting a small Vert.x
>> 2 project; how does one register a java based verticle on the bus? In
>> Vert.x 2 I used to do this:
>>
>> ...
>> public void start() {
>> vertx.eventBus().registerHandler("foohandler",
>> new Handler>() { ...

Note this is Java 8 so you don't need horrible new Handler() { public
void handle() {}} anonymous class stuff any more, you can use lambdas as
Julien showed above.

[Jordan Halterman]

I thought I liked this at first, but once I started porting Vertigo to Vert.x 3 I found it kind of awkward to work with, though that may just be because I'm used to the Vert.x 2 API.

What is the argument for adding MessageConsumer? Just to add ReadStream and WriteStream to the event bus? I think I rather liked the simplicity and understandability of registerHandler.

[Rubin]

Thanks Tim + Julien!

Short extra question: I seem to remember Tim commenting that you can use
different message types now: Can one use "registerCodec" to specify a
message type? Can I use that to (for example) use Jackson's JsonNode as
a message type? A small code snippet would be excellent!

Rubin.

[Tim Fox]

On 14/11/14 17:49, Jordan Halterman wrote:
> I thought I liked this at first, but once I started porting Vertigo to Vert.x 3 I found it kind of awkward to work with, though that may just be because I'm used to the Vert.x 2 API.
>
> What is the argument for adding MessageConsumer? Just to add ReadStream and WriteStream to the event bus?

To main reasons:

1. It's a Readstream so you can use it with pumps / convert it into a Rx
observable
2. You can unregister it. Unregistering with the old interface was a
real pain.

[Tim Fox]

On 14/11/14 17:49, Jordan Halterman wrote:

> I thought I liked this at first, but once I started porting Vertigo to Vert.x 3 I found it kind of awkward to work with, though that may just be because I'm used to the Vert.x 2 API.
>
> What is the argument for adding MessageConsumer? Just to add ReadStream and WriteStream to the event bus? I think I rather liked the simplicity and understandability of registerHandler.

Maybe we could add a convenience method in EventBus:

MessageConsumer registerHandler(String address, Handler<> handler);

which still returns a MessageConsumer but with the handler already set.
That woulf look pretty much the same as the old API.

[Jordan Halterman]

I think the benefits of exposing the event bus as a ReadStream and WriteStream are pretty obvious and a great decision, but:
- Types seem inconsistent: consumer() returns a MessageConsumer which extends ReadStream and sender() and publisher() return a WriteStream. I realize this is probably just because there was no need for additional methods on the WriteStream, but neither can you add event bus specific WriteStream methods later if you want/need to
- Methods exposed by the interface seem inconsistent: I can send() or publish() messages by calling those methods directly on the EventBus API *or* I can create a sender() or publisher(), but to receive messages I can only create a consumer() and use that to consume messages. Does the event bus provide an interface that allows you to send/receive messages, or does it provide addressed streams that allow you to send/receive messages, or does it do both? Right now it does both for sending but one for receiving.

I think the thing that felt awkward or more complex to me was having to hang on to a MessageConsumer in order to unregister it later, but I think that's fine. And maybe producer/consumer behaviors differ enough to warrant the asymmetric API that I mentioned above. Just thought I'd give some thoughts from my symmetric thinking mind.

Jordan Halterman

[Julien Viet]

Hi Jordan,

on MessageConsumer<T> (that extends ReadStream<Message<T>> indeed) you have bodyStream() that gives you a ReadStream<T>, so you can chain and write : consumer(“foo”).bodyStream() .

--
Julien Viet
www.julienviet.com

On 14 Nov 2014 at 22:29:37, Jordan Halterman (jordan.h...@gmail.com) wrote:
> I think the benefits of exposing the event bus as a ReadStream and WriteStream are pretty
> obvious and a great decision, but:
> - Types seem inconsistent: consumer() returns a MessageConsumer which extends ReadStream
> and sender() and publisher() return a WriteStream. I realize this is probably just because
> there was no need for additional methods on the WriteStream, but neither can you add event
> bus specific WriteStream methods later if you want/need to
> - Methods exposed by the interface seem inconsistent: I can send() or publish() messages
> by calling those methods directly on the EventBus API *or* I can create a sender() or publisher(),
> but to receive messages I can only create a consumer() and use that to consume messages.
> Does the event bus provide an interface that allows you to send/receive messages, or
> does it provide addressed streams that allow you to send/receive messages, or does it
> do both? Right now it does both for sending but one for receiving.
>
> I think the thing that felt awkward or more complex to me was having to hang on to a MessageConsumer
> in order to unregister it later, but I think that's fine. And maybe producer/consumer
> behaviors differ enough to warrant the asymmetric API that I mentioned above. Just thought
> I'd give some thoughts from my symmetric thinking mind.
>
> Jordan Halterman
>

[Julien Viet]

the asymmetric publish/send <-> consume has always been there, it is not something new in V3.

--
Julien Viet
www.julienviet.com

On 14 Nov 2014 at 22:29:37, Jordan Halterman (jordan.h...@gmail.com) wrote:

> I think the benefits of exposing the event bus as a ReadStream and WriteStream are pretty
> obvious and a great decision, but:
> - Types seem inconsistent: consumer() returns a MessageConsumer which extends ReadStream
> and sender() and publisher() return a WriteStream. I realize this is probably just because
> there was no need for additional methods on the WriteStream, but neither can you add event
> bus specific WriteStream methods later if you want/need to
> - Methods exposed by the interface seem inconsistent: I can send() or publish() messages
> by calling those methods directly on the EventBus API *or* I can create a sender() or publisher(),
> but to receive messages I can only create a consumer() and use that to consume messages.
> Does the event bus provide an interface that allows you to send/receive messages, or
> does it provide addressed streams that allow you to send/receive messages, or does it
> do both? Right now it does both for sending but one for receiving.
>
> I think the thing that felt awkward or more complex to me was having to hang on to a MessageConsumer
> in order to unregister it later, but I think that's fine. And maybe producer/consumer
> behaviors differ enough to warrant the asymmetric API that I mentioned above. Just thought
> I'd give some thoughts from my symmetric thinking mind.
>
> Jordan Halterman
>

[Jordan Halterman (kuujo)]

I see what the confusion was here. I said two ways of sending and one of receiving I meant:

vertx.eventBus().send("foo", "Hello world!");

and

vertx.eventBus().sender("foo").write("Hello world!");

vs

vertx.eventBus().consumer("foo").handler(...);

sorry, would have written an example but wasn't at a computer :-)

[Julien Viet]

we kept the simple send form for simplicity.

we could add back the handler (that would return the underlying MessageConsumer for later unregistration or other operations).


--
Julien Viet
www.julienviet.com

[Tim Fox]

On 14/11/14 22:49, Jordan Halterman (kuujo) wrote:

I see what the confusion was here. I said two ways of sending and one of receiving I meant:

vertx.eventBus().send("foo", "Hello world!");

and

vertx.eventBus().sender("foo").write("Hello world!");

vs

vertx.eventBus().consumer("foo").handler(...);

Earlier I suggested adding...

MesssageConsumer consumer = vertx.eventBus().consumer("foo", reply -> {
});

As a shortcut to

MesssageConsumer consumer = vertx.eventBus().consumer("foo").handler(...);

Which should make things more symetrical. Does that makes sense?

(BTW symmetry is for squares! (and triangles and pentagons and...))

[Julien Viet]

good idea

--
Julien Viet
www.julienviet.com

On 14 Nov 2014 at 23:56:39, Tim Fox (timv...@gmail.com) wrote:
> On 14/11/14 22:49, Jordan Halterman (kuujo) wrote:
> > I see what the confusion was here. I said two ways of sending and one
> > of receiving I meant:
> >
> > |
> > vertx.eventBus().send("foo","Hello world!");
> > |
> >
> > and
> >
> > |
> > vertx.eventBus().sender("foo").write("Hello world!");
> > |
> >
> > vs
> >
> > |
> > vertx.eventBus().consumer("foo").handler(...);
> > |
>
> Earlier I suggested adding...
>
> MesssageConsumer consumer = vertx.eventBus().consumer("foo", reply -> {
> });
>
> As a shortcut to
>
> MesssageConsumer consumer = vertx.eventBus().consumer("foo").handler(...);
>
> Which should make things more symetrical. Does that makes sense?
>
> (BTW symmetry is for squares! (and triangles and pentagons and...))
>
>
>
> >
> > sorry, would have written an example but wasn't at a computer :-)
> >
> >
> > On Friday, November 14, 2014 1:51:44 PM UTC-8, Julien Viet wrote:
> >
> > the asymmetric publish/send <-> consume has always been there, it
> > is not something new in V3.
> >
> > --
> > Julien Viet
> > www.julienviet.com
> >
> >
> > On 14 Nov 2014 at 22:29:37, Jordan Halterman

[Tim Fox]

I suppose the question we should be asking is "why would someone want to
create a MessageConsumer *without* setting a handler on it"?

[Julien Viet]

2 cases:

1/ to use the bodyStream() on the returned MessageConsumer

2/ for Rx* to transform the returned ReadStream into an Observable and then let the subscribe method register an handler for the Subscriber

--
Julien Viet
www.julienviet.com

[Jordan Halterman]

I think I do actually like that

Sent from my iPhone

[Jordan Halterman]

And that's a very good point that I hadn't even thought of

Sent from my iPhone

[Jordan Halterman (kuujo)]

Sorry to take over your question Rubin Simons  :-)

[Jordan Halterman]

Sorry, to clarify, I mean why not return a MessageProducer that extends WriteStream from sender() and publisher(). I'm not opposed to using ReadStream and WriteStream for the event bus. This is good. I'm not opposed to MessageConsumer being returned. This is good. I'm just opposed to WriteStream being returned from sender() and publisher() instead of some extension of WriteStream called, for instance, MessageProducer. It may not be immediately clear to some users that WriteStream is the opposite of MessageConsumer, whereas it would be obvious that my hypothetical MessageProducer *is* the opposite of MessageConsumer.

That is:
EventBus.sender() returns MessageProducer which extends WriteStream
EventBus.publisher() returns MessageProducer which extends WriteStream
EventBus.consumer() returns MessageConsumer which extends ReadStream

Sent from my iPhone

[Julien Viet]

ah ok.

so MessageProducer<T> would be an empty subclass of WriteStream<T>.

--
Julien Viet
www.julienviet.com

On 15 Nov 2014 at 01:10:55, Jordan Halterman (jordan.h...@gmail.com) wrote:
> Sorry, to clarify, I mean why not return a MessageProducer that extends WriteStream
> from sender() and publisher(). I'm not opposed to using ReadStream and WriteStream
> for the event bus. This is good. I'm not opposed to MessageConsumer being returned. This
> is good. I'm just opposed to WriteStream being returned from sender() and publisher()
> instead of some extension of WriteStream called, for instance, MessageProducer. It
> may not be immediately clear to some users that WriteStream is the opposite of MessageConsumer,
> whereas it would be obvious that my hypothetical MessageProducer *is* the opposite
> of MessageConsumer.
>
> That is:
> EventBus.sender() returns MessageProducer which extends WriteStream
> EventBus.publisher() returns MessageProducer which extends WriteStream
> EventBus.consumer() returns MessageConsumer which extends ReadStream
>
> Sent from my iPhone
>

[Rubin]

:-) Hijacked! If someone could only quickly post a code snippet showing
how you can use registerCodec (a follow-up question that got buried in
the thread)..

Fwiw, I agree that returning MessageProducer/MessageConsumer would at
least look nicer and feel more intuitive than MessageConsumer/WriteStream.

Kind regards,


Rubin!

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to vertx+un...@googlegroups.com

> <mailto:vertx+un...@googlegroups.com>.

[Tim Fox]

On 15/11/14 09:16, Rubin wrote:
> :-) Hijacked! If someone could only quickly post a code snippet showing
> how you can use registerCodec

Take a look at the test suite :)

[Julien Viet]

So actually we ran into an issue a few weeks ago related to generics that force us to create sub interfaces of ReadStream/WriteStream when the generic type is a class and we introduced Stream subclasses to fix it.

Considering this + the fact that some day we may want to enrich the publisher/sender I’m in favour to add a MessageProducer instead of using WriteStream as return type. As you said this makes the API more symmetric and people won’t try to understand why there is a MessageConsumer and not a MessageProducer.

--
Julien Viet
www.julienviet.com


On 15 Nov 2014 at 10:03:44, Julien Viet (jul...@julienviet.com) wrote:
> ah ok.
>
> so MessageProducer would be an empty subclass of WriteStream.

[Julien Viet]

Hi,

the MessageProducer and the simplified MessageConsumer registration have been added in Vertx master after quick discussions on the vertx-dev list.

--
Julien Viet
www.julienviet.com