[undertow-dev] Enable HTTP/2 and get JDK9 ALPN not supported

Steve Hu stevehu at gmail.com
Sun Mar 19 20:07:33 EDT 2017


I am reading the code in client package and they look really good. As
currently none of the http/2 client library has a work around on alpn boot
jar and this blocks majority of developers to move to http/2. I am
wondering if you want to split client package to a standalone client module
so that it can be used by other developers to connect to servers that
implement http/2. If you are interested in it, I can help to create a pull
request and add some test cases while I am working on my own client
implementation. Thanks.

On Sun, Mar 19, 2017 at 5:32 PM, Stuart Douglas <sdouglas at redhat.com> wrote:

> You could use Undertow's HTTP/2 client, although it's API was designed
> around the reverse proxy use case and as a result is not ideal for the
> general purpose HTTP client use case (although it is still perfectly
> usable).
>
> In terms of using Undertow's ALPN implementation with Netty etc it
> would require someone to port it over. The code is at [1] if you are
> interested.
>
> Stuart
>
> [1] https://github.com/undertow-io/undertow/blob/master/core/
> src/main/java/io/undertow/protocols/ssl/ALPNHackSSLEngine.java
>
> On Mon, Mar 20, 2017 at 7:21 AM, Steve Hu <stevehu at gmail.com> wrote:
> > Thanks Stuart for the quick response. Now I have server started with
> HTTP/2
> > and it works perfect with some client tools. Now I am looking for Java
> > HTTP/2 client libraries to update my client module to support HTTP/2
> > protocol for microservices communication. There are three major libraries
> > okhttp, jetty and netty but all of them require Jetty's ALPN boot JAR. I
> saw
> > you have resolved the boot jar dependency in Undertow and am wondering if
> > you could point me to the right direction. Do you have any recommendation
> > for HTTP/2 client library? How do you work around the alpn boot jar? Is
> the
> > same solution can be used by okhttp, jetty and netty before Java 9 is
> > released?
> >
> >
> >
> > On Fri, Mar 17, 2017 at 11:03 PM, Stuart Douglas <sdouglas at redhat.com>
> > wrote:
> >>
> >> No, that is a debug level message. The JDK8 ALPN provider should still
> >> be registered.
> >>
> >> Stuart
> >>
> >> On Sat, Mar 18, 2017 at 12:18 PM, Steve Hu <stevehu at gmail.com> wrote:
> >> > Hi,
> >> >
> >> > I searched this mailing list and one post mentioned that I don't need
> to
> >> > use
> >> > -Xbootclasspath/p:<path_to_alpn_boot_jar> after 1.4.0Final. I am
> trying
> >> > HTTP/2 on my server with 1.4.10 and Oracle JDK 1.8 but when I start
> the
> >> > server I got the following error. Do I have to use OpenJDK 8? If I
> >> > switch to
> >> > JBoss OpenSSL implementation?
> >> >
> >> > Thanks,
> >> >
> >> > Steve
> >> >
> >> > 21:00:36.468 [main]  DEBUG io.undertow - Configuring listener with
> >> > protocol
> >> > HTTPS for interface 0.0.0.0 and port 8843
> >> >
> >> > 21:00:36.486 [main]  DEBUG io.undertow - JDK9 ALPN not supported
> >> >
> >> > java.lang.NoSuchMethodException:
> >> > javax.net.ssl.SSLParameters.setApplicationProtocols([
> Ljava.lang.String;)
> >> >
> >> > at java.lang.Class.getMethod(Class.java:1786)
> >> >
> >> > at
> >> >
> >> > io.undertow.protocols.alpn.JDK9AlpnProvider$1.run(
> JDK9AlpnProvider.java:47)
> >> >
> >> > at
> >> >
> >> > io.undertow.protocols.alpn.JDK9AlpnProvider$1.run(
> JDK9AlpnProvider.java:43)
> >> >
> >> > at java.security.AccessController.doPrivileged(Native Method)
> >> >
> >> > at
> >> >
> >> > io.undertow.protocols.alpn.JDK9AlpnProvider.<clinit>(
> JDK9AlpnProvider.java:43)
> >> >
> >> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> >> >
> >> > at
> >> >
> >> > sun.reflect.NativeConstructorAccessorImpl.newInstance(
> NativeConstructorAccessorImpl.java:62)
> >> >
> >> > at
> >> >
> >> > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(
> DelegatingConstructorAccessorImpl.java:45)
> >> >
> >> > at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> >> >
> >> > at java.lang.Class.newInstance(Class.java:442)
> >> >
> >> > at
> >> > java.util.ServiceLoader$LazyIterator.nextService(
> ServiceLoader.java:380)
> >> >
> >> > at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> >> >
> >> > at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> >> >
> >> > at io.undertow.protocols.alpn.ALPNManager.<init>(ALPNManager.java:40)
> >> >
> >> > at io.undertow.protocols.alpn.ALPNManager.<clinit>(
> ALPNManager.java:35)
> >> >
> >> > at
> >> >
> >> > io.undertow.server.protocol.http.AlpnOpenListener.<init>(
> AlpnOpenListener.java:67)
> >> >
> >> > at
> >> >
> >> > io.undertow.server.protocol.http.AlpnOpenListener.<init>(
> AlpnOpenListener.java:90)
> >> >
> >> > at io.undertow.Undertow.start(Undertow.java:179)
> >> >
> >> > at com.networknt.server.Server.start(Server.java:170)
> >> >
> >> > at com.networknt.server.Server.main(Server.java:90)
> >> >
> >> > 21:00:36.503 [main]  INFO  com.networknt.server.Server - Https Server
> >> > started on ip:0.0.0.0 Port:8843
> >> >
> >> >
> >> > _______________________________________________
> >> > 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/20170319/0d9e29de/attachment.html 


More information about the undertow-dev mailing list