On Wed, 25 Nov 2020 at 17:18, Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > > > On Wed, Nov 25, 2020 at 5:46 AM Kabir Khan <kkhan(a)redhat.com&gt; wrote: > >> >> >> On Tue, 24 Nov 2020 at 18:46, Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> >>> >>> On Tue, Nov 24, 2020 at 3:38 AM Kabir Khan <kkhan(a)redhat.com&gt; wrote: >>> >>>> Hi, >>>> >>>> One thing missing in the proposal >>>> <https://github.com/wildfly/wildfly-proposals/pull/320> 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 >>>> <https://github.com/wildfly-extras/wildfly-mp-reactive-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 :) >> >>> >>> >>>> Thanks, >>>> >>>> Kabir >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >>> >>> >>> >>> -- >>> Brian Stansberry >>> Manager, Senior Principal Software Engineer >>> Red Hat >>> >> > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat >