[wildfly-dev] ALPN support

Wed Jan 14 03:39:26 EST 2015

> On 14 Jan 2015, at 00:01, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:
> 
> 
> 
> On Wed Jan 14 2015 at 1:54:34 AM Brian Stansberry <brian.stansberry at redhat.com> 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. 
Or add it to the launcher API but deprecate the methods to do so right away?
> 
> Stuart
>  
> 
> > Stuart
> >
> > On Wed Jan 07 2015 at 2:39:27 PM Jason T. Greene
> > <jason.greene at redhat.com <mailto:jason.greene at 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 at gmail.com <mailto:stuart.w.douglas at 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...stuartwdouglas:alpn
> >>     _______________________________________________
> >>     wildfly-dev mailing list
> >>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev