We should probably download these jars using a directory or file name convention that is associated with the particular jvm version. That way it becomes easy to support multiple jvm version environments which is very common (both in domain and standalone). In domain mode we could have the host controller bootstrap follow the same approach as standalone. For domain server configured jvms we could reuse the logic as part of the JVM argument building process. On Jan 6, 2015, at 7:20 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com&gt; wrote: Hi all, Both SPDY and the upcoming HTTP2 protocol require the use of an SSL extension called ALPN (Application Layer Protocol Negotiation). Unfortunately this is not supported in current JDK's (it should appear in JDK9), so the only way to support these protocols in Java at the moment is to modify the boot class path and override the JDK SSL classes to add support for this. In practice this means add jetty-alpn-boot.jar to the boot class path, however the exact version of the jar that is required depends on the JVM version, which means we can't just ship a jar and add the boot class path stuff to our startup scripts. I have come up with a proof on concept[1] for how to deal with this, that will download the appropriate ALPN jar for the current server if -alpn is passed to the startup script, however we still need some way to handle this in domain mode, where we need to make sure the servers are all started with the appropriate parameter (worst case we could just require users to install the appropriate JAR themselves, and then set the appropriate JAVA_OPTS). Hopefully the need for this will go away with Java 9, so I am not sure how much effort we should spend dealing with this. Does anyone have any thoughts on this? Stuart [1] https://github.com/stuartwdouglas/wildfly-core/compare/wildfly:master...s... _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

So I guess the real issue for domain mode is how we actually tell the configured servers to use the ALPN jar, especially given that this situation will likely be temporary, and not be required for Java 9+. One option could be that if the -alpn option is passed to the host controller on boot then all servers that it spawns will also have alpn on the boot class path, but that just seems really hacky.

Another option would be to just require the user to setup the correct -Xbootclasspath option manually in the JVM arguments. This is not very user friendly though.

Stuart On Wed Jan 07 2015 at 2:39:27 PM Jason T. Greene <jason.greene(a)redhat.com <mailto:jason.greene@redhat.com>> wrote: We should probably download these jars using a directory or file name convention that is associated with the particular jvm version. That way it becomes easy to support multiple jvm version environments which is very common (both in domain and standalone). In domain mode we could have the host controller bootstrap follow the same approach as standalone. For domain server configured jvms we could reuse the logic as part of the JVM argument building process. On Jan 6, 2015, at 7:20 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com <mailto:stuart.w.douglas@gmail.com>> wrote: > Hi all, > Both SPDY and the upcoming HTTP2 protocol require the use of an > SSL extension called ALPN (Application Layer Protocol > Negotiation). Unfortunately this is not supported in current JDK's > (it should appear in JDK9), so the only way to support these > protocols in Java at the moment is to modify the boot class path > and override the JDK SSL classes to add support for this. > > In practice this means add jetty-alpn-boot.jar to the boot class > path, however the exact version of the jar that is required > depends on the JVM version, which means we can't just ship a jar > and add the boot class path stuff to our startup scripts. > > I have come up with a proof on concept[1] for how to deal with > this, that will download the appropriate ALPN jar for the current > server if -alpn is passed to the startup script, however we still > need some way to handle this in domain mode, where we need to make > sure the servers are all started with the appropriate parameter > (worst case we could just require users to install the appropriate > JAR themselves, and then set the appropriate JAVA_OPTS). > > Hopefully the need for this will go away with Java 9, so I am not > sure how much effort we should spend dealing with this. > > Does anyone have any thoughts on this? > > Stuart > > [1] > https://github.com/stuartwdouglas/wildfly-core/compare/wildfly:master...s... > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 14 Jan 2015, at 00:01, Stuart Douglas <stuart.w.douglas(a)gmail.com&gt; wrote: On Wed Jan 14 2015 at 1:54:34 AM Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: On 1/11/15 8:00 PM, Stuart Douglas wrote: > So I guess the real issue for domain mode is how we actually tell the > configured servers to use the ALPN jar, especially given that this > situation will likely be temporary, and not be required for Java 9+. > > One option could be that if the -alpn option is passed to the host > controller on boot then all servers that it spawns will also have alpn > on the boot class path, but that just seems really hacky. > The launcher stuff that James has done is meant to allow mirroring of our script behavior via a java API. So if we're adding stuff like this into the scripts it should go into the launcher too. Otherwise tools can't replicate script behavior. At least not without coding it up themselves. If it's in the launcher API it's not that hacky to pass the flag through to the HC process so it knows to use it. The whole thing is quite yuck though so (no offense meant) so I feel squeamish advocating putting it in the launcher API. Yea, this whole thing is really yuck. > Another option would be to just require the user to setup the correct > -Xbootclasspath option manually in the JVM arguments. This is not very > user friendly though. > A third yuck option is to use RuntimeMXBean.getBootClassPath() and do hackery to identify "foreign" stuff, and then have the PC use that when creating the HC process and have the HC use it when creating server processes. But I like just having people configure it better. It's a pretty edgy case and it falls within the parameters of how a jvm config is meant to be used. I think the bigger question is whether this ends up in the launcher API. I would rather it didn't, especially because this will hopefully all be unnecessary once Java 9 comes out. So now I am thinking we just document how to set this up, and once Java 9 is out and we support their new ALPN API we just require Java 9 for HTTP2 support.

Stuart > Stuart > > On Wed Jan 07 2015 at 2:39:27 PM Jason T. Greene > <jason.greene(a)redhat.com <mailto:jason.greene@redhat.com>> wrote: > > We should probably download these jars using a directory or file > name convention that is associated with the particular jvm version. > That way it becomes easy to support multiple jvm version > environments which is very common (both in domain and standalone). > > In domain mode we could have the host controller bootstrap follow > the same approach as standalone. For domain server configured jvms > we could reuse the logic as part of the JVM argument building process. > > On Jan 6, 2015, at 7:20 PM, Stuart Douglas > <stuart.w.douglas(a)gmail.com <mailto:stuart.w.douglas@gmail.com>> wrote: > >> Hi all, >> Both SPDY and the upcoming HTTP2 protocol require the use of an >> SSL extension called ALPN (Application Layer Protocol >> Negotiation). Unfortunately this is not supported in current JDK's >> (it should appear in JDK9), so the only way to support these >> protocols in Java at the moment is to modify the boot class path >> and override the JDK SSL classes to add support for this. >> >> In practice this means add jetty-alpn-boot.jar to the boot class >> path, however the exact version of the jar that is required >> depends on the JVM version, which means we can't just ship a jar >> and add the boot class path stuff to our startup scripts. >> >> I have come up with a proof on concept[1] for how to deal with >> this, that will download the appropriate ALPN jar for the current >> server if -alpn is passed to the startup script, however we still >> need some way to handle this in domain mode, where we need to make >> sure the servers are all started with the appropriate parameter >> (worst case we could just require users to install the appropriate >> JAR themselves, and then set the appropriate JAVA_OPTS). >> >> Hopefully the need for this will go away with Java 9, so I am not >> sure how much effort we should spend dealing with this. >> >> Does anyone have any thoughts on this? >> >> Stuart >> >> [1] >> https://github.com/stuartwdouglas/wildfly-core/compare/wildfly:master...s... >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev