[wildfly-dev] Re: Configure vert.x in WildFly

Thanks, for this, Lin! It's possible to maintain things in an external FP code base but still integrate them into std WF. This is how the mvc-krazo extension works. I'm not going to pretend that's particularly comfortable though, and it would need some thought whether there's a sufficient benefit to it. The basic benefit would be that the external FP could do more releases independent of WF. We do pretty frequent releases though! The other benefit would be if the extension wanted to experiment with changes that can't be handled using the stability level approach. But a lot of things can be modeled using stability levels. A third benefit would be that in general I think it would be good if some extensions were maintained externally. But I don't think something like this that's meant to be used by other extensions is a good candidate for that. Speaking of stability levels.... I think this subsystem would come into WF as at most Preview stability, but we have existing default stability uses of Vert.x. So the integration of this must bridge that gap. Perhaps via hooks in the existing uses such that if a capability provided by this subsystem is available, use it, otherwise fall back to the existing way of integrating vert.x. Re the 3 "Feature decision" questions, I'll comment on the doc. On Tue, Aug 27, 2024 at 10:11 AM Kabir Khan <kkhan(a)redhat.com&gt; wrote: > I added my comments to the document. > > IMO the main use case that **I** am after is the ability to configure > vert.x options, and I think it makes sense to put that part into WildFly > since it will be consumed by reactive messaging and Otel. > > That said, it would be great to be able to continue having the > extra functionality that I am not bothered about coming in via the feature > pack. This depends a bit on if it is possible to augment the subsystem I > would like to see in WildFly with this extra stuff. Some alternatives might > be a new vertx-extras subsystem providing additional information, or > perhaps we could simply make the additional features a lower stability > level so that users have to opt in somehow. > > Thanks, > > Kabir > > > > On Tue, 27 Aug 2024 at 16:09, Lin Gao <lgao(a)redhat.com&gt; wrote: > >> Thanks Brian. >> >> The extension provides more features than needed to address the issue >> above[1], so I think it would be great to have a public discussion on which >> one is needed and how to get it integrated into WildFly first, so I created >> a doc at: >> https://docs.google.com/document/d/1gvVB3_Uh_urPZdc3eej9i7yotLDRJWBkapybC... >> for the discussion. >> >> Any comment is more than welcome :) >> >> [1] >> https://github.com/smallrye/smallrye-reactive-messaging/discussions/2725 >> >> Best regards >> >> On Mon, Aug 26, 2024 at 9:48 PM Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> >>> >>> On Sat, Aug 24, 2024 at 11:24 PM Lin Gao <lgao(a)redhat.com&gt; wrote: >>> >>>> Hello, >>>> >>>> Sorry for the late response, I was away last week. >>>> >>>> Yes, I did some research on developing a Vertx subsystem for WildFly, >>>> which has the capabilities to configure Vertx options. >>>> Now only one Vertx instance can be configured with the subsystem, and >>>> the Vertx instance can be referenced by other subsystems via the capability >>>> name. >>>> >>>> I think one Vertx instance should be good enough to cover most cases >>>> unless there are demands for multiple instances. >>>> >>>> @Brian, what should I do to move the wildfly-vertx-extension to >>>> wildfly-extras ? I am willing to do that shortly if applicable :) Thank you >>>> very much ! >>>> >>> >>> When you're ready, find me on Zulip when we're both online and we can >>> work through the process. It only takes a few minutes. I'm online in the >>> evening often. Or, feel free to put something in my calendar and we'll meet >>> then. It's generally no problem at all for you to put something on my >>> calendar between 19:00 and 21:30 US Central Daylight Time. >>> >>> >>>> Best regards >>>> >>>> On Tue, Aug 20, 2024 at 11:27 PM Brian Stansberry < >>>> brian.stansberry(a)redhat.com&gt; wrote: >>>> >>>>> Lin Gao has done a lot in this area, so be sure to discuss with him: >>>>> >>>>> https://github.com/gaol/wildfly-vertx-extension >>>>> >>>>> This was something we'd discussed moving to wildfly-extras last year. >>>>> >>>>> On Tue, Aug 20, 2024 at 8:05 AM Jason Lee <jasondlee(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> (SmallRye) OpenTelemetry does use vert.x for its exporters, so there >>>>>> is definitely some overlap. I'm not sure what, if any, configuration >>>>>> options might be of interest there or what the implications of a shared >>>>>> vert.x instance might be off hand, but it certainly sounds like something >>>>>> worth investigating. >>>>>> >>>>>> Jason Lee >>>>>> >>>>>> Principal Software Engineer >>>>>> >>>>>> Red Hat JBoss EAP >>>>>> >>>>>> Java Champion >>>>>> >>>>>> >>>>>> On Tue, Aug 20, 2024 at 3:02 AM Kabir Khan <kkhan(a)redhat.com&gt; wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> At the moment the SmallRye/MP Reactive Messaging integration just >>>>>>> uses a default created vert.x. >>>>>>> >>>>>>> I think otel uses vert.x too, probably in much the same way? Then >>>>>>> there might be other subsystems in various feature packs. >>>>>>> >>>>>>> It seems there is some desire to be able to configure the vert.x >>>>>>> instance >>>>>>> https://github.com/smallrye/smallrye-reactive-messaging/discussions/2725. >>>>>>> Being able to configure vert.x is TBH something I've totally ignored. >>>>>>> >>>>>>> I guess this would mean a Vert.X subsystem, which can optionally >>>>>>> create a vert.x instance with the configured parameters. Does it make sense >>>>>>> to create more than one instance in case subsystems have slightly different >>>>>>> needs? >>>>>>> >>>>>>> Then the reactive messaging subsystem can use that, if present (or >>>>>>> perhaps this should be a configuration parameter in the reactive messaging >>>>>>> subsystem). If not (or not configured to do so), it will use the default >>>>>>> like it does today. >>>>>>> >>>>>>> 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 >>>>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>>>> List Archives: >>>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>>> List Archives: >>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>>> >>>>> >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Principal Architect, Red Hat JBoss EAP >>>>> WildFly Project Lead >>>>> He/Him/His >>>>> >>>> >>>> >>>> -- >>>> Lin Gao >>>> Senior Software Engineer >>>> JBoss Sustaining Engineering Team >>>> >>>> >>> >>> -- >>> Brian Stansberry >>> Principal Architect, Red Hat JBoss EAP >>> WildFly Project Lead >>> He/Him/His >>> >> >> >> -- >> Lin Gao >> Senior Software Engineer >> JBoss Sustaining Engineering Team >> >> -- Brian Stansberry Principal Architect, Red Hat JBoss EAP WildFly Project Lead He/Him/His