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> 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