<br><br><div class="gmail_quote">On Wed Jan 14 2015 at 1:54:34 AM Brian Stansberry <<a href="mailto:brian.stansberry@redhat.com">brian.stansberry@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 1/11/15 8:00 PM, Stuart Douglas wrote:<br>
> So I guess the real issue for domain mode is how we actually tell the<br>
> configured servers to use the ALPN jar, especially given that this<br>
> situation will likely be temporary, and not be required for Java 9+.<br>
><br>
> One option could be that if the -alpn option is passed to the host<br>
> controller on boot then all servers that it spawns will also have alpn<br>
> on the boot class path, but that just seems really hacky.<br>
><br>
<br>
The launcher stuff that James has done is meant to allow mirroring of<br>
our script behavior via a java API. So if we're adding stuff like this<br>
into the scripts it should go into the launcher too. Otherwise tools<br>
can't replicate script behavior. At least not without coding it up<br>
themselves.<br>
<br>
If it's in the launcher API it's not that hacky to pass the flag through<br>
to the HC process so it knows to use it.<br>
<br>
The whole thing is quite yuck though so (no offense meant) so I feel<br>
squeamish advocating putting it in the launcher API.<br></blockquote><div><br></div><div>Yea, this whole thing is really yuck. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Another option would be to just require the user to setup the correct<br>
> -Xbootclasspath option manually in the JVM arguments. This is not very<br>
> user friendly though.<br>
><br>
<br>
A third yuck option is to use RuntimeMXBean.<u></u>getBootClassPath() and do<br>
hackery to identify "foreign" stuff, and then have the PC use that when<br>
creating the HC process and have the HC use it when creating server<br>
processes. But I like just having people configure it better. It's a<br>
pretty edgy case and it falls within the parameters of how a jvm config<br>
is meant to be used.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think the bigger question is whether this ends up in the launcher API.<br></blockquote><div><br></div><div>I would rather it didn't, especially because this will hopefully all be unnecessary once Java 9 comes out. </div><div><br></div><div>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. </div><div><br></div><div>Stuart</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Stuart<br>
><br>
> On Wed Jan 07 2015 at 2:39:27 PM Jason T. Greene<br>
> <<a href="mailto:jason.greene@redhat.com" target="_blank">jason.greene@redhat.com</a> <mailto:<a href="mailto:jason.greene@redhat.com" target="_blank">jason.greene@redhat.<u></u>com</a>>> wrote:<br>
><br>
> We should probably download these jars using a directory or file<br>
> name convention that is associated with the particular jvm version.<br>
> That way it becomes easy to support multiple jvm version<br>
> environments which is very common (both in domain and standalone).<br>
><br>
> In domain mode we could have the host controller bootstrap follow<br>
> the same approach as standalone. For domain server configured jvms<br>
> we could reuse the logic as part of the JVM argument building process.<br>
><br>
> On Jan 6, 2015, at 7:20 PM, Stuart Douglas<br>
> <<a href="mailto:stuart.w.douglas@gmail.com" target="_blank">stuart.w.douglas@gmail.com</a> <mailto:<a href="mailto:stuart.w.douglas@gmail.com" target="_blank">stuart.w.douglas@<u></u>gmail.com</a>>> wrote:<br>
><br>
>> Hi all,<br>
>> Both SPDY and the upcoming HTTP2 protocol require the use of an<br>
>> SSL extension called ALPN (Application Layer Protocol<br>
>> Negotiation). Unfortunately this is not supported in current JDK's<br>
>> (it should appear in JDK9), so the only way to support these<br>
>> protocols in Java at the moment is to modify the boot class path<br>
>> and override the JDK SSL classes to add support for this.<br>
>><br>
>> In practice this means add jetty-alpn-boot.jar to the boot class<br>
>> path, however the exact version of the jar that is required<br>
>> depends on the JVM version, which means we can't just ship a jar<br>
>> and add the boot class path stuff to our startup scripts.<br>
>><br>
>> I have come up with a proof on concept[1] for how to deal with<br>
>> this, that will download the appropriate ALPN jar for the current<br>
>> server if -alpn is passed to the startup script, however we still<br>
>> need some way to handle this in domain mode, where we need to make<br>
>> sure the servers are all started with the appropriate parameter<br>
>> (worst case we could just require users to install the appropriate<br>
>> JAR themselves, and then set the appropriate JAVA_OPTS).<br>
>><br>
>> Hopefully the need for this will go away with Java 9, so I am not<br>
>> sure how much effort we should spend dealing with this.<br>
>><br>
>> Does anyone have any thoughts on this?<br>
>><br>
>> Stuart<br>
>><br>
>> [1]<br>
>> <a href="https://github.com/stuartwdouglas/wildfly-core/compare/wildfly:master...stuartwdouglas:alpn" target="_blank">https://github.com/<u></u>stuartwdouglas/wildfly-core/<u></u>compare/wildfly:master...<u></u>stuartwdouglas:alpn</a><br>
>> ______________________________<u></u>_________________<br>
>> wildfly-dev mailing list<br>
>> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.<u></u>jboss.org</a>><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/<u></u>mailman/listinfo/wildfly-dev</a><br>
><br>
><br>
><br>
> ______________________________<u></u>_________________<br>
> wildfly-dev mailing list<br>
> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/<u></u>mailman/listinfo/wildfly-dev</a><br>
><br>
<br>
<br>
--<br>
Brian Stansberry<br>
Senior Principal Software Engineer<br>
JBoss by Red Hat<br>
______________________________<u></u>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/<u></u>mailman/listinfo/wildfly-dev</a><br>
</blockquote></div>