I think that this would be a great enhancement. Thanks for proposing it! The only concern I would have is around fault-tolerance. From what I can tell, from the Quarkus documentation, the Quarkus event bus uses Vert.x EventBus which does not guarantee message delivery if failure of part of the event bus occurs [1]. However, we can easily make sure that we use Quarkus's SmallRye Fault Tolerance [2]. Is my rough understanding inline with your proposal?
Go community, Adam [1]: https://vertx.io/docs/apidocs/io/vertx/core/eventbus/EventBus.html [2]: https://quarkus.io/guides/smallrye-fault-tolerance On Fri, Nov 7, 2025 at 11:49 AM Alexandre Dutra <[email protected]> wrote: > Hi all, > > I'd like to propose an enhancement to our existing events feature: the > ability to support multiple listeners. > > Currently, only a single listener can be active at a time, which is > quite limiting. For example, we might need to persist events for audit > purposes and simultaneously send them to a message queue for > optimization. With the current setup, this isn't easily achievable. > > While a composite listener could be created, it feels like a less > elegant solution, and the delivery would be strictly serial, > processing one listener after another. > > My suggestion is to leverage Quarkus internal event bus [1]: > > 1) There will be one central event emitter responsible for publishing > events to the bus. > > 2) We will have zero to N listeners, each independently watching the > event bus for relevant events. They will be discovered by CDI. > > 3) We could apply filters to each listener, e.g. listener A listens > for event types X and Y, listener B only listens to event type Y. > > 4) This approach would ensure fully asynchronous delivery of events to > all interested listeners. > > 5) Fault-tolerance could also be easily implemented (event delivery > retries, timeouts, etc.). > > What do you all think? > > Thanks, > Alex > > [1]: https://quarkus.io/guides/reactive-event-bus >
