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
