Make the Smallrye ReactiveMessaging Extension consider/operate on Producer methods.

[lennartj]

Reactive messaging should work with Producer methods

Today the ReactiveMessagingExtension only considers Fields as CDI InjectionPoints for Emitters and Consumer methods annotated with @Channel.

This requires us to create and maintain lots of complex code for each reactive messaging endpoint whenever we want an integration to behave differently in different environments, typically not to be active in Development or simple injection of custom configuration mechanics. Should the ReactiveMessagingExtension consider @Produces-annotated methods, this complexity is removed entirely.

This would also make the SR RM development model compliant with standard CDI mechanics in regards to Disposers, corresponding to Producers - which means a good stepping stone towards reconfigurability in runtime.

[lennartj]

CDI Producer methods provide a generic way of creating Emitters. Some implications of this:

• The EmitterFactoryFor annotation seems introduced to enable separate specification types for Emitters as illustrated in the EmitterFactoryExamples class. It also mandates a common Emitter configuration (EmitterConfiguration) and API (T createEmitter(EmitterConfiguration configuration, long defaultBufferSize);).
• A CDI producer method is extensible enough that any Emitter (or Publisher) subclass can be generated in the producer method body. Adding a CDI @Typed annotation can simply expose the custom interfaces to CDI in its default manner - and therefore achieve the same effect without introducing extra annotations or conceptual models.
• I would therefore argue that a CDI Producer method implies that the development model meets the required flexibility without complicating the development model by introducing additional types to the Smallrye RM API.

[ozangunalp]

@lennartj the original issue you created and the Emitter Factory feature are two different things.

Reactive Messaging works on CDI-managed beans and detects declared channels/emitters in order to create necessary streams on connectors, verify the completeness and link them together. This happens at deployment time, so the application startup. (In Quarkus, it is done at build-time) At runtime, CDI is used to discover those channels/emitters and if necessary are injected into managed beans but everything is already in place for streams to process messages.

Producer methods don't make sense as they provide implementations for objects to be injected. They also enable implementation variability at runtime that would not be supported by reactive messaging.

EmitterFactorys on the other hand are for providing custom emitter interfaces, other than the default ones, Emitter and MutinyEmitter. They are used by the framework to create the emitter implementation and the framework registers this implementation as an emitter. The EmitterFactory implementations are producer beans for the CDI to inject custom typed emitter into the application.

So back to your original requirement, while the reactive messaging doesn't provide the runtime variability by design, you can disable individual channels with configuration: http://smallrye.io/smallrye-reactive-messaging/3.18.0/concepts/advanced-config/ You just need to make sure that the channel is not used by the application.