My POC downloads a mapping file, that maps the JVM version to a specific
On Wed Jan 07 2015 at 2:39:27 PM Jason T. Greene <jason.greene(a)redhat.com>
We should probably download these jars using a directory or file
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>
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 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
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?
wildfly-dev mailing list