I missed out wildfly-dev at some point, re-adding so the full thread is public

On Wed, 25 Nov 2020 at 17:33, Kabir Khan <kkhan@redhat.com> wrote:

On Wed, 25 Nov 2020 at 17:18, Brian Stansberry <brian.stansberry@redhat.com> wrote:

On Wed, Nov 25, 2020 at 5:46 AM Kabir Khan <kkhan@redhat.com> wrote:

On Tue, 24 Nov 2020 at 18:46, Brian Stansberry <brian.stansberry@redhat.com> wrote:

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. :)

s/a layer/a layer or layers/g
In WildFly I currently have layers for:
* the two subsystems
* the kafka connector

Are you saying you would like something like a microprofile-reactive layer (similar to microprofile-platform)? 

No, I just meant we want good layer coverage, as that is the best approach for letting people tailor their config. I didn't see the word layer in your email. :)

If so, I think I would just include the two core subsystem layers and leave the connector out, as there may be more in the future and as you once mentioned elsewhere we don't want those to magically show up in provisioned servers in future releases. On that note, note that context propagation will be added soonish and probably should be part of the microprofile-reactive layer once it shows up. It sort of breaks the 'rule' but less so than a bunch of reactive messaging connectors showing up :)

Maybe at some point a microprofile-reactive layer would make sense but not until it has a clear fixed meaning that we can comfortably evolve, and better yet *not evolve*. It is much better if a layer in version Y does not produce significantly differ results vs previous version X.  

I don't know enough to have an opinion about a kafka connector layer. I should probably look at the analysis doc and the code!

BTW for folks who weren't aware, this is why the 'microprofile-platform' layer is called 'microprofile-platform' and not 'microprofile'.  A layer named 'microprofile' would be too open ended so people using it would not be able to predict how it would evolve. Would new MP-related subsystem 'foo' be added when WF introduces it? The 'microprofile-platform' layer means the things in MP platform that WF provides, so if we add something and it is a platform spec we will add it to that layer, and if you use that layer and upgrade, you'll get it. If you don't want that, then use the individual layers for the specs you want.
That's fine, I was happy with the layers I already have :) 

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.
+1 I can add my stuff easily in tests and wherever else, I just needed to stop guessing how this should work :)



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

Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat