1.1. CDI observers and Vert.x message consumers

Vert.x makes use of a light-weight distributed messaging system to allow application components to communicate in a loosely coupled way. weld-vertx-core makes it possible to notify CDI observer methods when a message is sent via Vert.x event bus. A simple echo message consumer example:

Since we’re working with a regular observer method, additional parameters may be declared (next to the event parameter). These parameters are injection points. So it’s easy to declare a message consumer dependencies:

1.1.1. How does it work?

The central point of integration is the org.jboss.weld.vertx.VertxExtension.
Its primary task is to find all CDI observer methods that should be notified when a message is sent via io.vertx.core.eventbus.EventBus.

If a Vertx instance is available during CDI bootstrap, then VertxExtension also:

registers a Vert.x handler for each address found (whenever a new message is delivered to the handler, Event.fire() is used to notify all observers bound to a specific address)

Handlers use Vertx.executeBlocking() since we expect the code to be blocking.

org.jboss.weld.vertx.WeldVerticle starts/stops the Weld SE container and registers VertxExtension automatically. However, VertxExtension.registerConsumers(Vertx, Event<Object>) could be also used after the bootstrap, e.g. when a Vertx instance is only available after a CDI container is initialized.

1.2. CDI-powered Verticles

It’s also possible to deploy Verticles produced/injected by Weld, e.g.:

1.3. AsyncReference

CDI bean instance creation is synchronous.
As a result if you inject a bean whose initialization involves potentially blocking operations (e.g. fetching some data from DB) the creation process is blocked until the dependency is ready.
AsyncReference is an asynchronously processed wrapper of an injectable reference (also implements CompletionStage) which allows to finish the client bean creation before a dependency is ready.
It’s suitable e.g. when injecting a bean whose creation involves potentially blocking operations:

If there is a producer method whose return type is CompletionStage where the result type matches the required type and has all the required qualifers (according to type-safe resolution rules) then CompletionStage#whenComplete(java.util.function.BiConsumer) is used to process the reference.
Otherwise, a worker thread is used so that the processing does not block the event loop thread.

1.4. AsyncWorker

AsyncWorker allows to wrap a synchronous action as an asynchronous computation.
The action is performed either as blocking operation using a Vertx worker thread or as non-blocking operation using the Vertx event-loop thread:

2.1. Declaring routes in a declarative way

weld-vertx-web extends weld-vertx-core and vertx-web functionality and allows to automatically register Route handlers and observer methods discovered during container initialization.
In other words, it’s possible to configure a Route in a declarative way - using org.jboss.weld.vertx.web.WebRoute annotation.
The target can be a class which implements Handler<RoutingContext>:

Constructed handler instances are not CDI contextual intances.
In other words, they’re not managed by the CDI container (similarly as Java EE components like servlets).
However, dependency injection, interceptors and decorators are supported:

@WebRoute is a repeatable annotation.
This means that multiple annotations may be declared on a handler class or an observer method.
In this case, a handler instance or an observer method is used for multiple routes.

2.2. How does it work?

The central point of the module is the org.jboss.weld.vertx.web.RouteExtension.
Its primary task is to find all handler classes and observer methods annotated with @WebRoute and register routes through RouteExtension.registerRoutes(Router).

weld-vertx-service-proxy does not depend directly on weld-vertx-core. However, the default implementation of org.jboss.weld.vertx.serviceproxy.ServiceProxySupport relies on the functionality provided by weld-vertx-core.

3.1. Injecting Service Proxies

A service proxy interface annotated with io.vertx.codegen.annotations.ProxyGen is automatically discovered and a custom bean with @Dependent scope and org.jboss.weld.vertx.serviceproxy.ServiceProxy qualifier is registered.

@ApplicationScoped
public class EchoServiceConsumer {
// Injects a service proxy for a service with the given address
@Inject
@ServiceProxy("echo-service-address")
EchoService service;
@Inject
@Echo
Event<String> event;
public void doEchoBusiness(String value) {
// By default, the result handler is executed by means of Vertx.executeBlocking()
// In this case, we fire a CDI event observed by EchoObserver bean
service.echo(value, (r) -> event.fire(r.result()));
}
}

4.1. How does it work?

Just add weld-vertx-probe to the classpath, set the org.jboss.weld.development system property to true and use WeldWebVerticle to register the routes defined declaratively (as defined in How does it work?).