{

"outcome" => "failed",

"failure-description" => {

"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.https" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service

Caused by: java.lang.IllegalStateException: WFLYUT0079: No SSL Context available from security realm. Either the realm is not configured for SSL, or the server has not been reloaded since the SSL config was added."},

"WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.listener.https"],

"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined

"rolled-back" => true,

"response-headers" => {"process-state" => "reload-required"}

}

On Mon, Apr 24, 2017 at 6:24 AM Stuart Douglas <sdouglas@redhat.com> wrote:

Ah, I just skim read your first email and did not realize you were
talking about the OkHttp client, and not the native Undertow
client/server. Even though Undertow has support for ALPN natively
using other clients will require the jar.

How have you attempted to add the jar to the boot class path? You
probably want to add it to JAVA_OPTS in standalone.conf.

Stuart

On Sat, Apr 22, 2017 at 4:57 AM, Hanan Othman <hothman@webalo.com> wrote:
> So what you mean is that I should be able to use OkHttp inside WildFly
> 10.1 without having to do any additional setup? Might there be a reason
> why this is not what I am seeing currently?
>
> On Fri, Apr 21, 2017 at 12:01 AM, Stuart Douglas <sdouglas@redhat.com>
> wrote:
>>
>> On Fri, Apr 21, 2017 at 1:17 AM, Hanan Othman <hothman@webalo.com> wrote:
>> > Yes, I am. The same jar works outside of WildFly.
>> >
>> > Can you tell me about the other solution that WildFly 10.1 uses?
>>
>> It uses a different approach that does not require replacing the boot
>> class path jars. It should just work out of the box on any Oracle or
>> OpenJDK JVM.
>>
>> Stuart
>>
>> >
>> > On Thu, Apr 20, 2017 at 4:42 PM, Tomaž Cerar <tomaz.cerar@gmail.com>
>> > wrote:
>> >>
>> >> Hey,
>> >>
>> >> are you using proper version of apln-boot jar that applies to your
>> >> exact
>> >> version of jdk?
>> >>
>> >> Since 10.1, WildFly itself doesn't use the apln-boot hack anymore
>> >> since,
>> >> but uses different solution in undertow that doesn't require patching
>> >> jdk
>> >> classes.
>> >>
>> >> --
>> >> tomaz
>> >>
>> >> On Thu, Apr 20, 2017 at 3:58 PM, Hanan Othman <hothman@webalo.com>
>> >> wrote:
>> >>>
>> >>> Hello undertow-dev,
>> >>>
>> >>> I'm trying to use WildFly to send a push notification to iOS devices,
>> >>> which requires the use of HTTP/2. Using OkHttp
>> >>> (http://square.github.io/okhttp/), I was able to send a request
>> >>> successfully
>> >>> in an external java project using the JVM option:
>> >>> -Xbootclasspath/p:<path-to-alpn-boot-jar>.
>> >>>
>> >>> After checking the documentation here:
>> >>> http://undertow.io/blog/2015/03/26/HTTP2-In-Wildfly.html, I was unable
>> >>> to do
>> >>> the same in WildFly. When I run the server I get:
>> >>>
>> >>> okhttp3.OkHttpClient -- ALPN callback dropped: SPDY and HTTP/2 are
>> >>> disabled. Is alpn-boot on the boot class path?
>> >>>
>> >>>
>> >>> which leads me to think that it is not actually on the classpath. I
>> >>> have
>> >>> the same configuration as that in the blog post, except having Wildfly
>> >>> 10.0.1.Final instead of Wildfly 9.0.0.Beta1. I have the correct
>> >>> alpn-boot
>> >>> jar version since it already works outside of WildFly, but I do not
>> >>> know
>> >>> what else I could be missing. Thank you very much for your time.
>> >>>
>> >>> Best,
>> >>> Hanan
>> >>>
>> >>> _______________________________________________
>> >>> undertow-dev mailing list
>> >>> undertow-dev@lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > undertow-dev mailing list
>> > undertow-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>