I missed out wildfly-dev at some point, re-adding so the full thread is
On Wed, 25 Nov 2020 at 17:33, Kabir Khan <kkhan(a)redhat.com> wrote:
On Wed, 25 Nov 2020 at 17:18, Brian Stansberry <
> On Wed, Nov 25, 2020 at 5:46 AM Kabir Khan <kkhan(a)redhat.com> wrote:
>> On Tue, 24 Nov 2020 at 18:46, Brian Stansberry <
>> brian.stansberry(a)redhat.com> wrote:
>>> On Tue, Nov 24, 2020 at 3:38 AM Kabir Khan <kkhan(a)redhat.com> wrote:
>>>> One thing missing in the proposal
>>>> 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
>>>> WildFly I am not sure what to do. In a way the reactive specs are
>>>> 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
>>>> 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
>>>> 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
>>>> pack. Inclusion of these is presently a pure Galleon layers thing, but
>>>> 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
>>> 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
>> 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
> 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'
> 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
>>> 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(a)lists.jboss.org
>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
>>> Brian Stansberry
>>> Manager, Senior Principal Software Engineer
>>> Red Hat
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat