From robin.anil at gmail.com Fri Apr 5 12:45:53 2019 From: robin.anil at gmail.com (Robin Anil) Date: Fri, 5 Apr 2019 11:45:53 -0500 Subject: [undertow-dev] Lightweight integration tests In-Reply-To: References:

Message-ID: Hi Undertow-dev Could you see this request. Apologies for pinging Stuart directly. But I am looking for ways to write tests that exercise the undertow handler chain tests going through the network. Robin On Wed, Mar 20, 2019 at 6:11 PM Stuart Douglas wrote: > Not in the near future. I have mostly been working on Quarkus for the > moment, and Flavia has taken over as Undertow lead (I am still involved in > the project, I just don't have as much time to spend on it). > > Stuart > > On Thu, Mar 21, 2019 at 2:02 AM Robin Anil wrote: > >> Stuart, just checking in again, is doing a local invocation of handlers >> without involving network on your radar? >> >> Robin >> >> On Thu, Mar 15, 2018 at 4:44 PM Robin Anil wrote: >> >>> Not a lot of data. But most of our handlers are very fast and out test >>> suite is in the 2000 range and increasing >>> >>> - from a phone, xquz typoz >>> >>> On Mar 15, 2018 4:35 PM, "Stuart Douglas" wrote: >>> >>> For servlet there >>> is io.undertow.servlet.handlers.ServletInitialHandler#dispatchMockRequest, >>> however it is Servlet only at the moment and it pretty basic. >>> >>> That said though I am currently looking at adding support for a new >>> client+proxy implementation, and one of the things I want to support is >>> local invocation without involving the network, so doing a more general >>> version of this was on my radar. >>> >>> I am still surprised that the network is causing issues for your >>> integration tests though. How much data are these tests sending? >>> >>> Stuart >>> >>> On Fri, Mar 16, 2018 at 6:14 AM, Robin Anil >>> wrote: >>> >>>> Hi Stuart, >>>> >>>> Is there a way to bring up undertow programmatically where the >>>> underlying HTTP/https transport is removed in favor or direction function >>>> calls >>>> >>>> Effectively, we have accumulated a lot of integration tests and are >>>> looking for ways to speed them up and at the moment, 80% of CPU time in the >>>> test is pretty data copies back and forth at the HTTP client and HTTP >>>> server. >>>> >>>> Before I start refactoring our HTTP-handler chains to fake-undertow, I >>>> thought it might be good to ask. >>>> >>>> >>>> Robin >>>> >>> >>> >>> >> >> -- >> >> [image: Tock] >> >> >> Robin Anil >> Director of Engineering >> >> Tock / exploretock.com >> >> > -- [image: Tock] Robin Anil Director of Engineering Tock / exploretock.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190405/c4bd056c/attachment-0001.html From notabenem at hotmail.com Wed Apr 10 02:49:37 2019 From: notabenem at hotmail.com (=?iso-8859-1?Q?M=E1ty=E1s_Bene?=) Date: Wed, 10 Apr 2019 06:49:37 +0000 Subject: [undertow-dev] How to feed data to websockets from an external source Message-ID: Hi all, I would appreciate any kind of guidance and information about how to use undertow in a scenario where we'd like to poll an external source for messages (e.g. kafka) and feed those messages to all the connected websocket sessions. So far the only examples I've found were about mirroring the messages received from http/websockets back to other websocket sessions or write those messages to Kafka. What we'd ideally need is READ from kafka (e.g. using a dedicated thread, busy-spinning and polling) and pass the retrieved data to undertow (ideally within the JVM without going through HTTP / REST) that would then send them over websockets to the connected clients. A separate, but related question is, assuming that we were to use the websocket-JSR interface, that is it safe to assume that undertow ensures that at any given time only a single thread is writing to a specific websocket session, especially when using the asyncremote.send() method? Would undertow be able to paralellize all the async send operations using multiple threads to speed up sending? M. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190410/06623d3a/attachment.html From sdouglas at redhat.com Thu Apr 11 20:27:39 2019 From: sdouglas at redhat.com (Stuart Douglas) Date: Fri, 12 Apr 2019 10:27:39 +1000 Subject: [undertow-dev] Undertow 3.0 Announcement Message-ID: The Java network programming world has come a long way since Undertow was first started. Netty has emerged as the de-facto standard for network programming in Java, and the Undertow team has decided that the benefits of utilising Netty outweigh any benefits in keeping our XNIO based transport layer. Undertow 3.0 will keep Undertow?s programming model, however the underlying transport will be changed from XNIO to Netty. We will also use the Netty HTTP/1, HTTP/2 and Websocket implementations. We believe this change will have a number of advantages: - It will allow other Netty based services (e.g GRPC) to share the same HTTP port - It allows sharing of threads between Undertow and other Netty based services, resulting in services using less resources - The underlying transport implementation are the most complex part of Undertow, delegating this to Netty will significantly reduce the work needed to maintain Undertow As part of this Flavia Rainone will be taking over as project lead from Stuart Douglas so he can focus on the recently announced Quarkus project, however Stuart will continue to be heavily involved in Undertow for the foreseeable future. Flavia Rainone has been involved in JBoss community since 2002 and has an extensive background on Remoting and Xnio. In the past years, she acted as EJB component lead for WildFly, besides contributing to several projects in WildFly, such as IronJacamar, JBoss MSC and XNIO, and also Byteman. All this makes her a good fit for taking over Undertow leadership. What does this mean for me? What this means for you will depend on which parts of Undertow you are using: - If you are using the Servlet API then you will likely not notice any change. You will need some different dependencies (Netty instead of XNIO), however the rest of the experience should be mostly identical - If you are using the low level Undertow HttpHandler and HttpServerExchange and you want to use Undertow 3.0 then you will need to migrate your application. For the most part this migration should be straightforward, as most concepts from the old API directly map to the new API. Road Map 2.x The existing Undertow 2.x branch will continue to be maintained for the foreseeable future. It will receive bug and security fixes, and some features, however it is unlikely to receive any more low level transport oriented features (e.g. HTTP/3 support). For now it is a perfectly valid choice to stay on Undertow 2 while the new Netty based implementation matures. 3.x A 3.0 final version should be released in the next few months, however in the short term the 3.x branch will not provide the same level of API compatibility that Undertow has traditionally provided. As the Netty implementation is new this will allow us to potentially fix any issues we find with our approach without being locked in to supporting an API that is not ideal. This is a great time to try out the new API and report and problems or suggestions. Note that this is explicitly referring to the core HttpServerExchange based API, no major plans are expected to the Servlet API (i.e. ServletExtension and DeploymentInfo). 4.x After a short 3.x cycle we are planning on releasing a 4.x that will provide API stability, in the same way that Undertow 1.x and 2.x have. How can I contribute You can contribute to Undertow in the same way it has always been done. We have an email list open for discussion here: undertow-dev at lists.jboss.org Jira issues can be accessed here: https://issues.jboss.org/projects/UNDERTOW/issues And source code for 3.x is here: https://github.com/undertow-io/undertow/tree/3.0.x Also, with the move from HipChat to Zulip in Wildfly team, you can now access Undertow stream via Zulip at https://wildfly.zulipchat.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190412/41181869/attachment.html From ckozak at ckozak.net Thu Apr 11 21:25:55 2019 From: ckozak at ckozak.net (Carter Kozak) Date: Thu, 11 Apr 2019 21:25:55 -0400 Subject: [undertow-dev] Undertow 3.0 Announcement In-Reply-To: References: Message-ID: <19e0b757-71fa-44c2-9679-c986b7a39e19@www.fastmail.com> This is exciting news! Would it be possible to publish snapshots from the 3.x branch to begin testing and migration of existing projects and libraries to new APIs? It looks like the zulipchat link is locked down to specific domains, and I'm unable to sign up. Thank you for all the incredible work you do on Undertow, it's truly a joy to work with. -ck On Thu, Apr 11, 2019, at 20:28, Stuart Douglas wrote: > The Java network programming world has come a long way since Undertow was first started. Netty has emerged as the de-facto standard for network programming in Java, and the Undertow team has decided that the benefits of utilising Netty outweigh any benefits in keeping our XNIO based transport layer. > > Undertow 3.0 will keep Undertow?s programming model, however the underlying transport will be changed from XNIO to Netty. We will also use the Netty HTTP/1, HTTP/2 and Websocket implementations. We believe this change will have a number of advantages: > > * It will allow other Netty based services (e.g GRPC) to share the same HTTP port > * It allows sharing of threads between Undertow and other Netty based services, resulting in services using less resources > * The underlying transport implementation are the most complex part of Undertow, delegating this to Netty will significantly reduce the work needed to maintain Undertow > > As part of this Flavia Rainone will be taking over as project lead from Stuart Douglas so he can focus on the recently announced Quarkus project, however Stuart will continue to be heavily involved in Undertow for the foreseeable future. > > Flavia Rainone has been involved in JBoss community since 2002 and has an extensive background on Remoting and Xnio. In the past years, she acted as EJB component lead for WildFly, besides contributing to several projects in WildFly, such as IronJacamar, JBoss MSC and XNIO, and also Byteman. All this makes her a good fit for taking over Undertow leadership. > > > *What does this mean for me?* > > What this means for you will depend on which parts of Undertow you are using: > > * If you are using the Servlet API then you will likely not notice any change. You will need some different dependencies (Netty instead of XNIO), however the rest of the experience should be mostly identical > * If you are using the low level Undertow HttpHandler and HttpServerExchange and you want to use Undertow 3.0 then you will need to migrate your application. For the most part this migration should be straightforward, as most concepts from the old API directly map to the new API. > > *Road Map* > > *2.x* > > The existing Undertow 2.x branch will continue to be maintained for the foreseeable future. It will receive bug and security fixes, and some features, however it is unlikely to receive any more low level transport oriented features (e.g. HTTP/3 support). For now it is a perfectly valid choice to stay on Undertow 2 while the new Netty based implementation matures. > > *3.x* > > A 3.0 final version should be released in the next few months, however in the short term the 3.x branch will not provide the same level of API compatibility that Undertow has traditionally provided. As the Netty implementation is new this will allow us to potentially fix any issues we find with our approach without being locked in to supporting an API that is not ideal. > > This is a great time to try out the new API and report and problems or suggestions. Note that this is explicitly referring to the core HttpServerExchange based API, no major plans are expected to the Servlet API (i.e. ServletExtension and DeploymentInfo). > > *4.x* > > After a short 3.x cycle we are planning on releasing a 4.x that will provide API stability, in the same way that Undertow 1.x and 2.x have. > > *How can I contribute* > > You can contribute to Undertow in the same way it has always been done. > > We have an email list open for discussion here: undertow-dev at lists.jboss.org > > Jira issues can be accessed here: https://issues.jboss.org/projects/UNDERTOW/issues > > And source code for 3.x is here: https://github.com/undertow-io/undertow/tree/3.0.x > > Also, with the move from HipChat to Zulip in Wildfly team, you can now access Undertow stream via Zulip at https://wildfly.zulipchat.com/ > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190411/a09c49b6/attachment-0001.html From frainone at redhat.com Fri Apr 12 15:35:05 2019 From: frainone at redhat.com (Flavia Rainone) Date: Fri, 12 Apr 2019 16:35:05 -0300 Subject: [undertow-dev] Lightweight integration tests In-Reply-To: References:

Message-ID: Robin, We don't have anything right now apart from io.undertow.servlet.handlers.ServletInitialHandler#dispatchMockRequest, so you will have to dig in and try to write a mock yourself. Maybe I'll add that to a future release plan but, for now, it is not on my radar either. Flavia On Fri, Apr 5, 2019 at 1:52 PM Robin Anil wrote: > Hi Undertow-dev > > Could you see this request. Apologies for pinging Stuart directly. But I > am looking for ways to write tests that exercise the undertow handler > chain tests going through the network. > > Robin > > On Wed, Mar 20, 2019 at 6:11 PM Stuart Douglas > wrote: > >> Not in the near future. I have mostly been working on Quarkus for the >> moment, and Flavia has taken over as Undertow lead (I am still involved in >> the project, I just don't have as much time to spend on it). >> >> Stuart >> >> On Thu, Mar 21, 2019 at 2:02 AM Robin Anil wrote: >> >>> Stuart, just checking in again, is doing a local invocation of handlers >>> without involving network on your radar? >>> >>> Robin >>> >>> On Thu, Mar 15, 2018 at 4:44 PM Robin Anil wrote: >>> >>>> Not a lot of data. But most of our handlers are very fast and out test >>>> suite is in the 2000 range and increasing >>>> >>>> - from a phone, xquz typoz >>>> >>>> On Mar 15, 2018 4:35 PM, "Stuart Douglas" wrote: >>>> >>>> For servlet there >>>> is io.undertow.servlet.handlers.ServletInitialHandler#dispatchMockRequest, >>>> however it is Servlet only at the moment and it pretty basic. >>>> >>>> That said though I am currently looking at adding support for a new >>>> client+proxy implementation, and one of the things I want to support is >>>> local invocation without involving the network, so doing a more general >>>> version of this was on my radar. >>>> >>>> I am still surprised that the network is causing issues for your >>>> integration tests though. How much data are these tests sending? >>>> >>>> Stuart >>>> >>>> On Fri, Mar 16, 2018 at 6:14 AM, Robin Anil >>>> wrote: >>>> >>>>> Hi Stuart, >>>>> >>>>> Is there a way to bring up undertow programmatically where the >>>>> underlying HTTP/https transport is removed in favor or direction function >>>>> calls >>>>> >>>>> Effectively, we have accumulated a lot of integration tests and are >>>>> looking for ways to speed them up and at the moment, 80% of CPU time in the >>>>> test is pretty data copies back and forth at the HTTP client and HTTP >>>>> server. >>>>> >>>>> Before I start refactoring our HTTP-handler chains to fake-undertow, I >>>>> thought it might be good to ask. >>>>> >>>>> >>>>> Robin >>>>> >>>> >>>> >>>> >>> >>> -- >>> >>> [image: Tock] >>> >>> >>> Robin Anil >>> Director of Engineering >>> >>> Tock / exploretock.com >>> >>> >> > > -- > > [image: Tock] > > > Robin Anil > Director of Engineering > > Tock / exploretock.com > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev -- Flavia Rainone Principal Software Engineer Red Hat TRIED. TESTED. TRUSTED -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190412/d7834c96/attachment.html From robin.anil at gmail.com Sat Apr 13 21:31:33 2019 From: robin.anil at gmail.com (Robin Anil) Date: Sat, 13 Apr 2019 20:31:33 -0500 Subject: [undertow-dev] Lightweight integration tests In-Reply-To: References:

Message-ID: Hi Flavia Is there a way to get access to ServletInitialHandler, from the built Undertow object? We don't use servlets, but add PathHandlers to UndertowBuilder to create Undertow server? Alternatively, would it be possible to make the server exchange data classes non-final, then we could expose our path handlers and exercise them from tests. https://issues.jboss.org/browse/UNDERTOW-560 On Fri, Apr 12, 2019 at 2:35 PM Flavia Rainone wrote: > Robin, > > We don't have anything right now apart from > io.undertow.servlet.handlers.ServletInitialHandler#dispatchMockRequest, so > you will have to dig in and try to write a mock yourself. Maybe I'll add > that to a future release plan but, for now, it is not on my radar either. > > Flavia > > On Fri, Apr 5, 2019 at 1:52 PM Robin Anil wrote: > >> Hi Undertow-dev >> >> Could you see this request. Apologies for pinging Stuart directly. But I >> am looking for ways to write tests that exercise the undertow handler >> chain tests going through the network. >> >> Robin >> >> On Wed, Mar 20, 2019 at 6:11 PM Stuart Douglas >> wrote: >> >>> Not in the near future. I have mostly been working on Quarkus for the >>> moment, and Flavia has taken over as Undertow lead (I am still involved in >>> the project, I just don't have as much time to spend on it). >>> >>> Stuart >>> >>> On Thu, Mar 21, 2019 at 2:02 AM Robin Anil wrote: >>> >>>> Stuart, just checking in again, is doing a local invocation of handlers >>>> without involving network on your radar? >>>> >>>> Robin >>>> >>>> On Thu, Mar 15, 2018 at 4:44 PM Robin Anil >>>> wrote: >>>> >>>>> Not a lot of data. But most of our handlers are very fast and out test >>>>> suite is in the 2000 range and increasing >>>>> >>>>> - from a phone, xquz typoz >>>>> >>>>> On Mar 15, 2018 4:35 PM, "Stuart Douglas" wrote: >>>>> >>>>> For servlet there >>>>> is io.undertow.servlet.handlers.ServletInitialHandler#dispatchMockRequest, >>>>> however it is Servlet only at the moment and it pretty basic. >>>>> >>>>> That said though I am currently looking at adding support for a new >>>>> client+proxy implementation, and one of the things I want to support is >>>>> local invocation without involving the network, so doing a more general >>>>> version of this was on my radar. >>>>> >>>>> I am still surprised that the network is causing issues for your >>>>> integration tests though. How much data are these tests sending? >>>>> >>>>> Stuart >>>>> >>>>> On Fri, Mar 16, 2018 at 6:14 AM, Robin Anil >>>>> wrote: >>>>> >>>>>> Hi Stuart, >>>>>> >>>>>> Is there a way to bring up undertow programmatically where the >>>>>> underlying HTTP/https transport is removed in favor or direction function >>>>>> calls >>>>>> >>>>>> Effectively, we have accumulated a lot of integration tests and are >>>>>> looking for ways to speed them up and at the moment, 80% of CPU time in the >>>>>> test is pretty data copies back and forth at the HTTP client and HTTP >>>>>> server. >>>>>> >>>>>> Before I start refactoring our HTTP-handler chains to fake-undertow, >>>>>> I thought it might be good to ask. >>>>>> >>>>>> >>>>>> Robin >>>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> >>>> [image: Tock] >>>> >>>> >>>> Robin Anil >>>> Director of Engineering >>>> >>>> Tock / exploretock.com >>>> >>>> >>> >> >> -- >> >> [image: Tock] >> >> >> Robin Anil >> Director of Engineering >> >> Tock / exploretock.com >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev > > > > -- > > Flavia Rainone > > Principal Software Engineer > > Red Hat > > > > TRIED. TESTED. TRUSTED > -- [image: Tock] Robin Anil Director of Engineering Tock / exploretock.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190413/3dfa2139/attachment-0001.html From darran.lofthouse at jboss.com Mon Apr 15 06:51:51 2019 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 15 Apr 2019 11:51:51 +0100 Subject: [undertow-dev] Undertow 3 API Migration Message-ID: I have been looking at the steps required to migrate the WildFly Elytron integration to Undertow 3 from Undertow 2. Overall it seems minimal changes are required but I was thinking if there could be an opportunity to evolve the API within Undertow 2 making migration to 3 easier in the future. One example being on SSSessionInfo we make use of the following method: - void renegotiate(HttpServerExchange exchange, SslClientAuthMode sslClientAuthMode) throws IOException; which has now been changed to: - void renegotiate(HttpServerExchange exchange, ClientAuth sslClientAuthMode) throws IOException; The first form is making use of Xnio API and the second is using Netty API. If this was deprecated in Undertow 2 and a pure Undertow variant added it could be usable both in 2 and 3. I suspect a number of the other changes breaking API compatibility could be handled in a similar way. Regards, Darran Lofthouse. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190415/19b7d294/attachment.html From miere.teixeira at gmail.com Mon Apr 15 07:29:10 2019 From: miere.teixeira at gmail.com (Miere Teixeira) Date: Mon, 15 Apr 2019 21:29:10 +1000 Subject: [undertow-dev] Undertow 3.0 Announcement In-Reply-To: References: Message-ID: Hi, It is indeed great news from the Undertow team. The arguments on picking Netty seems quite valid and makes perfect sense for a company as Red Hat to work closely to the community, focusing on new solutions that may put the company back as a reference in the JVM world. One question though that raised in my team lies on our continuous benchmark on Undertow since its 1.0.x version. As major features has been introduced, the performance has dropped by 12-15% depending on the hardware. It is also noticeable the performance difference between XNIO and Netty, where the Netty handles around 7.3-9% less requests/sec than XNIO. It may sound negligible at first glance, but some of my customers received custom implementations that relied on its remarkable performance to squeeze their software in a commodity hardware. In the mid-term, it means they will have an increase on their infrastructure cost. That being said, I'd like to take this opportunity to ask how RedHat and JBoss.org plans to cope with this sort of issue in the future, and which impact on this regard should we really expect. Kind Regards, Miere On Fri, Apr 12, 2019 at 10:28 AM Stuart Douglas wrote: > The Java network programming world has come a long way since Undertow was > first started. Netty has emerged as the de-facto standard for network > programming in Java, and the Undertow team has decided that the benefits of > utilising Netty outweigh any benefits in keeping our XNIO based transport > layer. > > Undertow 3.0 will keep Undertow?s programming model, however the > underlying transport will be changed from XNIO to Netty. We will also use > the Netty HTTP/1, HTTP/2 and Websocket implementations. We believe this > change will have a number of advantages: > > > - > > It will allow other Netty based services (e.g GRPC) to share the same > HTTP port > - > > It allows sharing of threads between Undertow and other Netty based > services, resulting in services using less resources > - > > The underlying transport implementation are the most complex part of > Undertow, delegating this to Netty will significantly reduce the work > needed to maintain Undertow > > > As part of this Flavia Rainone will be taking over as project lead from > Stuart Douglas so he can focus on the recently announced Quarkus project, > however Stuart will continue to be heavily involved in Undertow for the > foreseeable future. > > Flavia Rainone has been involved in JBoss community since 2002 and has an > extensive background on Remoting and Xnio. In the past years, she acted as > EJB component lead for WildFly, besides contributing to several projects > in WildFly, such as IronJacamar, JBoss MSC and XNIO, and also Byteman. All > this makes her a good fit for taking over Undertow leadership. > > > What does this mean for me? > > What this means for you will depend on which parts of Undertow you are > using: > > > - > > If you are using the Servlet API then you will likely not notice any > change. You will need some different dependencies (Netty instead of XNIO), > however the rest of the experience should be mostly identical > - > > If you are using the low level Undertow HttpHandler and > HttpServerExchange and you want to use Undertow 3.0 then you will need to > migrate your application. For the most part this migration should be > straightforward, as most concepts from the old API directly map to the new > API. > > > Road Map > > 2.x > > The existing Undertow 2.x branch will continue to be maintained for the > foreseeable future. It will receive bug and security fixes, and some > features, however it is unlikely to receive any more low level transport > oriented features (e.g. HTTP/3 support). For now it is a perfectly valid > choice to stay on Undertow 2 while the new Netty based implementation > matures. > > 3.x > > A 3.0 final version should be released in the next few months, however in > the short term the 3.x branch will not provide the same level of API > compatibility that Undertow has traditionally provided. As the Netty > implementation is new this will allow us to potentially fix any issues we > find with our approach without being locked in to supporting an API that is > not ideal. > > This is a great time to try out the new API and report and problems or > suggestions. Note that this is explicitly referring to the core > HttpServerExchange based API, no major plans are expected to the Servlet > API (i.e. ServletExtension and DeploymentInfo). > > 4.x > > After a short 3.x cycle we are planning on releasing a 4.x that will > provide API stability, in the same way that Undertow 1.x and 2.x have. > > How can I contribute > > You can contribute to Undertow in the same way it has always been done. > > We have an email list open for discussion here: > undertow-dev at lists.jboss.org > > Jira issues can be accessed here: > https://issues.jboss.org/projects/UNDERTOW/issues > > And source code for 3.x is here: > https://github.com/undertow-io/undertow/tree/3.0.x > > Also, with the move from HipChat to Zulip in Wildfly team, you can now > access Undertow stream via Zulip at https://wildfly.zulipchat.com/ > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190415/dcf911a4/attachment.html From sdouglas at redhat.com Mon Apr 15 18:42:12 2019 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 16 Apr 2019 08:42:12 +1000 Subject: [undertow-dev] Undertow 3 API Migration In-Reply-To: References: Message-ID: On Mon, Apr 15, 2019 at 8:59 PM Darran Lofthouse wrote: > I have been looking at the steps required to migrate the WildFly Elytron > integration to Undertow 3 from Undertow 2. > > Overall it seems minimal changes are required but I was thinking if there > could be an opportunity to evolve the API within Undertow 2 making > migration to 3 easier in the future. > > One example being on SSSessionInfo we make use of the following method: - > > void renegotiate(HttpServerExchange exchange, SslClientAuthMode > sslClientAuthMode) throws IOException; > > which has now been changed to: - > > void renegotiate(HttpServerExchange exchange, ClientAuth > sslClientAuthMode) throws IOException; > > The first form is making use of Xnio API and the second is using Netty API. > > If this was deprecated in Undertow 2 and a pure Undertow variant added it > could be usable both in 2 and 3. > This is a good idea. If you see areas where this can be done can you file a JIRA (or better yet open a PR)? In this case I think we should get rid of the Netty one entirely, and just have an agnostic one. Maybe we also need an Undertow 2.1 branch, which will aim to improve compatibility by adding methods like this that will work in both versions. Stuart > > I suspect a number of the other changes breaking API compatibility could > be handled in a similar way. > > Regards, > Darran Lofthouse. > > > > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190416/06c31074/attachment-0001.html From darran.lofthouse at jboss.com Tue Apr 16 04:48:48 2019 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 16 Apr 2019 09:48:48 +0100 Subject: [undertow-dev] Undertow 3 API Migration In-Reply-To: References: Message-ID: On Mon, Apr 15, 2019 at 11:42 PM Stuart Douglas wrote: > > This is a good idea. If you see areas where this can be done can you file > a JIRA (or better yet open a PR)? > Will start to get some PRs in - I think the executors are the hardest change but will start with these as I find them. > In this case I think we should get rid of the Netty one entirely, and just > have an agnostic one. > +1 I think once we have agnostic alternatives remove the Netty specifics from Undertow 3. > Maybe we also need an Undertow 2.1 branch, which will aim to improve > compatibility by adding methods like this that will work in both versions. > What is the policy regarding adding new API in 2.0 if this approach needs a minor version increment may be useful to get something started. > > Stuart > > >> >> I suspect a number of the other changes breaking API compatibility could >> be handled in a similar way. >> >> Regards, >> Darran Lofthouse. >> >> >> >> >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190416/77ecd105/attachment.html From sdouglas at redhat.com Tue Apr 16 04:58:29 2019 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 16 Apr 2019 18:58:29 +1000 Subject: [undertow-dev] Undertow 3 API Migration In-Reply-To: References: Message-ID: On Tue, Apr 16, 2019 at 6:49 PM Darran Lofthouse wrote: > > > On Mon, Apr 15, 2019 at 11:42 PM Stuart Douglas > wrote: > >> >> This is a good idea. If you see areas where this can be done can you file >> a JIRA (or better yet open a PR)? >> > > Will start to get some PRs in - I think the executors are the hardest > change but will start with these as I find them. > > >> In this case I think we should get rid of the Netty one entirely, and >> just have an agnostic one. >> > > +1 I think once we have agnostic alternatives remove the Netty specifics > from Undertow 3. > > >> Maybe we also need an Undertow 2.1 branch, which will aim to improve >> compatibility by adding methods like this that will work in both versions. >> > > What is the policy regarding adding new API in 2.0 if this approach needs > a minor version increment may be useful to get something started. > We have added new methods in micros before, but if we are doing a big chunk of them we should target 2.1. Stuart > > >> >> Stuart >> >> >>> >>> I suspect a number of the other changes breaking API compatibility could >>> be handled in a similar way. >>> >>> Regards, >>> Darran Lofthouse. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> undertow-dev mailing list >>> undertow-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/undertow-dev >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190416/d7e89c19/attachment.html From darran.lofthouse at jboss.com Tue Apr 16 05:05:02 2019 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 16 Apr 2019 10:05:02 +0100 Subject: [undertow-dev] Undertow 3 API Migration In-Reply-To: References: Message-ID: Ok, we we start to get PRs in and hold them back we can review how big a change we think this would become and apply to 2.1. On Tue, Apr 16, 2019 at 9:58 AM Stuart Douglas wrote: > > > On Tue, Apr 16, 2019 at 6:49 PM Darran Lofthouse < > darran.lofthouse at jboss.com> wrote: > >> >> >> On Mon, Apr 15, 2019 at 11:42 PM Stuart Douglas >> wrote: >> >>> >>> This is a good idea. If you see areas where this can be done can you >>> file a JIRA (or better yet open a PR)? >>> >> >> Will start to get some PRs in - I think the executors are the hardest >> change but will start with these as I find them. >> >> >>> In this case I think we should get rid of the Netty one entirely, and >>> just have an agnostic one. >>> >> >> +1 I think once we have agnostic alternatives remove the Netty specifics >> from Undertow 3. >> >> >>> Maybe we also need an Undertow 2.1 branch, which will aim to improve >>> compatibility by adding methods like this that will work in both versions. >>> >> >> What is the policy regarding adding new API in 2.0 if this approach needs >> a minor version increment may be useful to get something started. >> > > We have added new methods in micros before, but if we are doing a big > chunk of them we should target 2.1. > > Stuart > > >> >> >>> >>> Stuart >>> >>> >>>> >>>> I suspect a number of the other changes breaking API compatibility >>>> could be handled in a similar way. >>>> >>>> Regards, >>>> Darran Lofthouse. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> undertow-dev mailing list >>>> undertow-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190416/23af209e/attachment.html From paroczizs at gmail.com Thu Apr 18 04:42:46 2019 From: paroczizs at gmail.com (paroczizs) Date: Thu, 18 Apr 2019 10:42:46 +0200 Subject: [undertow-dev] (no subject) Message-ID: Hi Undertow Dev, I am using Wildfly 15.0.1, the microprofile metrics are enabled: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190418/de4a6f54/attachment.html From paroczizs at gmail.com Thu Apr 18 04:45:42 2019 From: paroczizs at gmail.com (paroczizs) Date: Thu, 18 Apr 2019 10:45:42 +0200 Subject: [undertow-dev] wildfly:microprofile-metrics + Undertow Message-ID: Hi Undertow Dev, I am using Wildfly 15.0.1, the microprofile metrics are enabled: the undertow module statistics is enavbled: however the /metrics page does not contains any http related statistics. Do I have to set any other configuration to see the undertow related statistics? Regards, Zsolt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190418/0a1dcbd3/attachment-0001.html From sdouglas at redhat.com Thu Apr 18 08:04:07 2019 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 18 Apr 2019 22:04:07 +1000 Subject: [undertow-dev] wildfly:microprofile-metrics + Undertow In-Reply-To: References: Message-ID: This is more a question for the WildFly forums, I am not really sure how this has been implemented in WildFly. Stuart On Thu, Apr 18, 2019 at 6:54 PM paroczizs wrote: > Hi Undertow Dev, > > I am using Wildfly 15.0.1, the microprofile metrics are enabled: > > security-enabled="false" exposed-subsystems="*"/> > > the undertow module statistics is enavbled: > > statistics-enabled="true"> > > however the /metrics page does not contains any http related statistics. > > Do I have to set any other configuration to see the undertow related > statistics? > > Regards, Zsolt > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190418/426b43fe/attachment.html From ckozak at ckozak.net Tue Apr 23 12:49:11 2019 From: ckozak at ckozak.net (Carter Kozak) Date: Tue, 23 Apr 2019 12:49:11 -0400 Subject: [undertow-dev] [3.x] HttpString migration Message-ID: Greetings, I'm curious what the plan is for HttpString in undertow 3.x, since this will potentially be the most frequent migration for components which don't implement custom xnio mechanisms. At the moment, the 3.x branch has replaced most uses of HttpString with String, however netty provides a similar AsciiString type which may provide similar performance characteristics to HttpString. Have we considered using the Netty type directly where HttpString is currently used, or using CharSequence instead of string since AsciiString already implements CharSequence, and HttpString may be updated to support it? Based on UNDERTOW-147 [1] I suppose there's some question as to whether or not a non-string type is desirable for Servlet uses. Thanks, Carter 1. https://issues.jboss.org/browse/UNDERTOW-147 From sdouglas at redhat.com Wed Apr 24 00:42:01 2019 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 24 Apr 2019 10:12:01 +0530 Subject: [undertow-dev] [3.x] HttpString migration In-Reply-To: References: Message-ID: This is one of the things I am not 100% sure about. I think CharSequence is probably the way to go, but I need to investigate the performance of the various options. With the Servlet API end users need to use String anyway, so if we made AsciiString part of the API we may end up with worse Servlet performance but better native handler performance, so there will probably be a trade off somewhere. Stuart On Tue, Apr 23, 2019 at 10:42 PM Carter Kozak wrote: > Greetings, > > I'm curious what the plan is for HttpString in undertow 3.x, since this > will potentially be the most frequent migration for components which don't > implement custom xnio mechanisms. At the moment, the 3.x branch has > replaced most uses of HttpString with String, however netty provides a > similar AsciiString type which may provide similar performance > characteristics to HttpString. Have we considered using the Netty type > directly where HttpString is currently used, or using CharSequence instead > of string since AsciiString already implements CharSequence, and HttpString > may be updated to support it? Based on UNDERTOW-147 [1] I suppose there's > some question as to whether or not a non-string type is desirable for > Servlet uses. > > Thanks, > Carter > > 1. https://issues.jboss.org/browse/UNDERTOW-147 > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190424/44c9c284/attachment.html From david.lloyd at redhat.com Wed Apr 24 09:51:00 2019 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 24 Apr 2019 08:51:00 -0500 Subject: [undertow-dev] [3.x] HttpString migration In-Reply-To: References:

Message-ID: Also worth noting is that the JDK recently introduced "compact strings", which allows for storage and creation of strings in 8-bit encoding under some circumstances. So String might actually be an okay long term choice in the end after all. References: - JEP 254 https://openjdk.java.net/jeps/254 - https://bugs.openjdk.java.net/browse/JDK-8054307 - https://dzone.com/articles/compact-strings-in-java-9 On Tue, Apr 23, 2019 at 11:43 PM Stuart Douglas wrote: > > This is one of the things I am not 100% sure about. I think CharSequence is probably the way to go, but I need to investigate the performance of the various options. > > With the Servlet API end users need to use String anyway, so if we made AsciiString part of the API we may end up with worse Servlet performance but better native handler performance, so there will probably be a trade off somewhere. > > Stuart > > On Tue, Apr 23, 2019 at 10:42 PM Carter Kozak wrote: >> >> Greetings, >> >> I'm curious what the plan is for HttpString in undertow 3.x, since this will potentially be the most frequent migration for components which don't implement custom xnio mechanisms. At the moment, the 3.x branch has replaced most uses of HttpString with String, however netty provides a similar AsciiString type which may provide similar performance characteristics to HttpString. Have we considered using the Netty type directly where HttpString is currently used, or using CharSequence instead of string since AsciiString already implements CharSequence, and HttpString may be updated to support it? Based on UNDERTOW-147 [1] I suppose there's some question as to whether or not a non-string type is desirable for Servlet uses. >> >> Thanks, >> Carter >> >> 1. https://issues.jboss.org/browse/UNDERTOW-147 >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev -- - DML From ckozak at ckozak.net Wed Apr 24 10:13:38 2019 From: ckozak at ckozak.net (Carter Kozak) Date: Wed, 24 Apr 2019 10:13:38 -0400 Subject: [undertow-dev] [3.x] HttpString migration In-Reply-To: References:

Message-ID: <68beeee5-40da-4a08-b014-47926330fb9f@www.fastmail.com> That's a good point, it looks like there's a relevant discussion here https://github.com/netty/netty/issues/8548 and https://github.com/netty/netty/issues/8540 On Wed, Apr 24, 2019, at 09:51, David Lloyd wrote: > Also worth noting is that the JDK recently introduced "compact > strings", which allows for storage and creation of strings in 8-bit > encoding under some circumstances. So String might actually be an > okay long term choice in the end after all. > > References: > - JEP 254 https://openjdk.java.net/jeps/254 > - https://bugs.openjdk.java.net/browse/JDK-8054307 > - https://dzone.com/articles/compact-strings-in-java-9 > > On Tue, Apr 23, 2019 at 11:43 PM Stuart Douglas wrote: > > > > This is one of the things I am not 100% sure about. I think CharSequence is probably the way to go, but I need to investigate the performance of the various options. > > > > With the Servlet API end users need to use String anyway, so if we made AsciiString part of the API we may end up with worse Servlet performance but better native handler performance, so there will probably be a trade off somewhere. > > > > Stuart > > > > On Tue, Apr 23, 2019 at 10:42 PM Carter Kozak wrote: > >> > >> Greetings, > >> > >> I'm curious what the plan is for HttpString in undertow 3.x, since this will potentially be the most frequent migration for components which don't implement custom xnio mechanisms. At the moment, the 3.x branch has replaced most uses of HttpString with String, however netty provides a similar AsciiString type which may provide similar performance characteristics to HttpString. Have we considered using the Netty type directly where HttpString is currently used, or using CharSequence instead of string since AsciiString already implements CharSequence, and HttpString may be updated to support it? Based on UNDERTOW-147 [1] I suppose there's some question as to whether or not a non-string type is desirable for Servlet uses. > >> > >> Thanks, > >> Carter > >> > >> 1. https://issues.jboss.org/browse/UNDERTOW-147 > >> _______________________________________________ > >> undertow-dev mailing list > >> undertow-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/undertow-dev > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > > -- > - DML > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190424/8551e3c6/attachment-0001.html From gomuppal at cisco.com Mon Apr 29 15:04:38 2019 From: gomuppal at cisco.com (Goutham Muppala (gomuppal)) Date: Mon, 29 Apr 2019 19:04:38 +0000 Subject: [undertow-dev] JWT implementation Message-ID: Hi All, I am trying to implement JWT token based authentication on wildfly 10.1.0.11. I don?t see any documentation related jwt token support for this version. Can anyone provide pointers on this? Thanks, Goutham -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190429/6887a441/attachment.html