7:45 p.m.
On Tue, Nov 24, 2020 at 3:38 AM Kabir Khan <kkhan(a)redhat.com> 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. :)
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.
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