On Tue, Nov 24, 2020 at 3:38 AM Kabir Khan <kkhan@redhat.com> wrote:

One thing missing in the proposal of the inclusion of MicroProfile Reactive Messaging (and RSO which is used by Reactive Messaging) is if we should add it to standalone-microprofile(-ha).xml or not?

As it previously came in via the feature pack it made sense to have it added from the FP, but now that it will be part of WildFly I am not sure what to do. In a way the reactive specs are separate from the other MP specs and not part of the MP platform, and adding the current MP platform is probably the main use-case for standalone-microprofile.xml?
At the same time I guess it could be nice for users to have something out of the box to run these. If we do not want it in standalone-microprofile.xml, do we want:

* an xml in docs/examples/configs 
* an enable-reactive.cli script in docs/examples

It is worth pointing out that what 'reactive' is will evolve: 
* We are currently only supporting RM 1.0, so we only need Reactive Messaging and RSO. Once RM .next is out it makes sense to also include Context Propagation (which is currently in the feature pack) to support 'user bridge' use cases. 
* All subsystems are currently empty, however we will look at making Reactive Messaging at least configurable going forward (to move stuff like connection info out from the MP config properties into something referenceable in the subsystem)
* RM can work without connectors. We are currently porting the Kafka connector, while the others (presently MQTT and AMQP) live in the feature pack. Inclusion of these is presently a pure Galleon layers thing, but once included may have impact on the subsystem implementations.

So perhaps we should either go with a pure documentation approach, or a minimal CLI script to turn these on. I'd be happy to hear your thoughts.

And a layer. :)

My instinct is we should avoid adding things into our standard config files. The pro of adding is things just work OOTB but the con is the many people who aren't really using things now have them and may not even notice. And then it is hard to take them away. So to put things in the standard configs I think we need to expect a pretty high level of use. That or they are required by some general 'meaning' of the config, e.g. a server running standalone-microprofile.xml being able to pass the MP *platform* TCKs.  I don't think the RM stuff will be high enough level of use yet.

We also know that the reactive stuff will be evolving after WF 23 we might be better off seeing what that looks like before adding things in the standard configs.

IIRC there's been discussion in the past of not adding more example configs and instead only including CLI scripts. OTOH maybe we are better off avoiding CLI scripts, which require writing by hand / manual maintenance and are fairly difficult to test.



wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org

Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat