Vertx CDI integration - introduce ConsumeEvent annotation

[mkouba]

@cescoffier @FroMage This is what I have so far. Let me know what you think about the API...

    @Dependent
    class SimpleBean {

        @ConsumeMessage("foo") // -> EventBus.consumer("foo").handler(m -> m.reply(m.body().toUpperCase()))
        String send(String message) {
            return message.toUpperCase();
        }

        @ConsumeMessage("pub") // -> EventBus.consumer("pub").handler(m -> System.out.println(message.body()))
        void pub(String message) {
          System.out.println(message);
        }

        @ConsumeMessage(value = "pub", local = true) // -> EventBus.localConsumer("pub").handler(m -> System.out.println(message.body()))
        void pub(Message<String> message) {
          System.out.println(message.body());
        }
        
        @ConsumeMessage("foo-async") // -> EventBus.consumer("foo-async").handler(m -> CompletableFuture.completedFuture(message.toUpperCase()).thenAccept(r -> m.reply(r)))
        CompletionStage<String> sendAsync(String message) {
            return CompletableFuture.completedFuture(message.toUpperCase());
        }
    }

WRT the annotation name - we cannot use @Consumes because of JAX-RS. I don't like @Address. And I find @ConsumeMessage quite self-explanatory.

[kenfinnigan]

It might open us up to unintended typos, but what about @Consume without the "s"?

[mkouba]

It might open us up to unintended typos...

I'm afraid this would not help much. We should try to avoid problems like CDI @Produces VS JAX-RS @Produces. Maybe @Consuming, @MessageConsumer or even @VertxConsumer?

[cescoffier]

I would use @Consumes.

For the rest, it looks very good!

[mkouba]

Well, I can see the users asking why it does not work and then realizing they use javax.ws.rs.Consumes. We had many similar questions about javax.ws.rs.Produces in CDI ;-)

[cescoffier]

You are right! Forgot about @Consumes. I would avoid message as it would confuse with reactive messaging. Maybe event something?

@Event
@EventHandler

...naming is hard....

[mkouba]

@ConsumeEvent sounds quite good... there will always be plenty of Event types on the class path.

@ConsumeEvent("foo.address")
String send(String message) {
    return message.toUpperCase();
}

[cescoffier]

+1 for @ConsumeEvent

[cescoffier]

Thinking loudly...

A few years back (in 2005), I've read a paper about using the class name to identify event recipient. Obviously, it was making the assumption that consumer would be "unique".

Now let's imagine a @ConsumeEvent without a value. Could we imagine to be the fully classified name of the bean class? Of course for a @Dependant bean it can be tricky but for an @ApplicationScoped bean it would work no?

[mkouba]

Like this?

package foo;
class SimpleBean { 
   @ConsumeMessage // -> EventBus.consumer("foo.SimpleBean").handler(m -> m.reply(m.body().toUpperCase())) 
   String send(String message) { return message.toUpperCase(); }
}

I think this would work for any scope. @Dependent bean instances exist to service a single delivery only.

[cescoffier]

Exactly.

[mkouba]

@cescoffier FQCN as the default address should work now.

[cescoffier]

A few comments inline.

[cescoffier]

All good!