ALPN unsupported. Is your classpatch configured correctly?

[Florian Müller]

help...please....8 hours spent on this issue but still not resolved!

Quick summary: we're trying to run pushy on a local Mac (El Capitan, JDK 1.8):

=> updated to OpenSSL 1.02 (openssl -version proves this)

=> added netty-tcnative as a dependency to our project:

<dependency>

            <groupId>io.netty</groupId>

            <artifactId>netty-tcnative</artifactId>

            <version>1.1.33.Fork9</version>

            <classifier>osx-x86_64</classifier>

</dependency>

=> added alpn-api to our POM

<dependency>

            <groupId>org.eclipse.jetty.alpn</groupId>

            <artifactId>alpn-api</artifactId>

            <version>1.1.2.v20150522</version>

            <scope>runtime</scope>

</dependency>

We are still facing the following exception, system has been entirely restarted etc etc:

Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [com.relayrides.pushy.apns.ApnsClient]: Factory method 'getPushy' threw exception; nested exception is java.lang.ExceptionInInitializerError

at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:189)

at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:588)

... 88 more

Caused by: java.lang.ExceptionInInitializerError

at io.netty.handler.ssl.JdkSslContext.toNegotiator(JdkSslContext.java:245)

at io.netty.handler.ssl.JdkSslClientContext.<init>(JdkSslClientContext.java:263)

at io.netty.handler.ssl.SslContext.newClientContextInternal(SslContext.java:739)

at io.netty.handler.ssl.SslContextBuilder.build(SslContextBuilder.java:319)

at com.relayrides.pushy.apns.ApnsClient.getSslContextWithCertificateAndPrivateKey(ApnsClient.java:277)

at com.relayrides.pushy.apns.ApnsClient.<init>(ApnsClient.java:241)

at com.relayrides.pushy.apns.ApnsClient.<init>(ApnsClient.java:219)

at ch.elvetino.eorder.CoreAdditionalConfiguration.getPushy(CoreAdditionalConfiguration.java:60)

at ch.elvetino.eorder.CoreAdditionalConfiguration$$EnhancerBySpringCGLIB$$7e60215b.CGLIB$getPushy$3(<generated>)

at ch.elvetino.eorder.CoreAdditionalConfiguration$$EnhancerBySpringCGLIB$$7e60215b$$FastClassBySpringCGLIB$$709ea1c9.invoke(<generated>)

at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228)

at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:309)

at ch.elvetino.eorder.CoreAdditionalConfiguration$$EnhancerBySpringCGLIB$$7e60215b.getPushy(<generated>)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:483)

at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:162)

... 89 more

Caused by: java.lang.RuntimeException: ALPN unsupported. Is your classpatch configured correctly? See http://www.eclipse.org/jetty/documentation/current/alpn-chapter.html#alpn-starting

at io.netty.handler.ssl.JdkAlpnApplicationProtocolNegotiator$1.<init>(JdkAlpnApplicationProtocolNegotiator.java:27)

at io.netty.handler.ssl.JdkAlpnApplicationProtocolNegotiator.<clinit>(JdkAlpnApplicationProtocolNegotiator.java:24)

... 107 more

Can you please help? Is anyone running this configuration sucessfully on a Mac? Can anyone see an issue in our configuration?

Any hep is highly appreciated...

Thanx a lot from Switzerland,

Florian

[Jon Chambers]

Florian,

It sounds like the netty-tcnative stuff isn't on the classpath of whatever is running Pushy. Just adding those dependencies to your POM may not be enough, and it sounds like this is a recurring point of confusion, particularly when using Pushy in a container environment. I'll try to learn a little more there, but in the meantime, please make sure netty-tcnative et al are on the classpath for your app container.

Hope that helps!

-Jon

--
Pushy is an open-source Java library for sending APNs (iOS and OS X) push notifications. Pushy is brought to you by the engineers at RelayRides.
---
You received this message because you are subscribed to the Google Groups "pushy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pushy-apns+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ryan Hartzfeld]

Hey Jon,

Same issue here.  I've tried adding the different profiles that apply the proper jetty.alpn.version property based off JDK (currently 1.8.0_45, FYI) and then adding following dependencies to my POM:

                <dependency>

                        <groupId>io.netty</groupId>

                        <artifactId>netty-tcnative</artifactId>

                        <version>1.1.33.Fork14</version>

                        <scope>runtime</scope>

                </dependency>

                <dependency>

            <groupId>org.mortbay.jetty.alpn</groupId>

            <artifactId>alpn-boot</artifactId>

            <version>${jetty.alpn.version}</version>

            <scope>runtime</scope>

        </dependency>

        <dependency>

            <groupId>org.eclipse.jetty.alpn</groupId>

            <artifactId>alpn-api</artifactId>

            <version>1.1.2.v20150522</version>

            <scope>runtime</scope> <!-- have also tried "provided" -->

        </dependency>

As you've stated, putting them in your POM might not be enough, so I've also used a similar method to what you have in pushy's own POM.xml.  I tried using the following to additions to my POM to get alpn-boot on the classpath at runtime:

<properties>

  <jetty.alpn.path>${settings.localRepository}/org/mortbay/jetty/alpn/alpn-boot/${jetty.alpn.version}/alpn-boot-${jetty.alpn.version}.jar</jetty.alpn.path>

 <argLine.bootcp>-Xbootclasspath/p:${jetty.alpn.path}</argLine.bootcp>

 <!-- ... -->
</properties>
<build>
  <plugins>
    <plugin> <!-- I don't think I can use surefire since this is not a "test" dependency? -->
      <groupId>or.apache.maven.plugins</groupId>
      <artifactId>maven-compiler-plugin</artifactId>
      <configuration>
        <compilerArgument>${argLine.bootcp}</compilerArgument>
      </configuration>
    </plugin>

    <!-- ... -->

  </plugins>
</build>

No matter how I've tried to configure this, I keep getting the same exception when firing up my Spring application.

Caused by: java.lang.RuntimeException: ALPN unsupported. Is your classpatch configured correctly? See http://www.eclipse.org/jetty/documentation/current/alpn-chapter.html#alpn-starting
 at io.netty.handler.ssl.JdkAlpnApplicationProtocolNegotiator$1.<init>(JdkAlpnApplicationProtocolNegotiator.java:27)
 at io.netty.handler.ssl.JdkAlpnApplicationProtocolNegotiator.<clinit>(JdkAlpnApplicationProtocolNegotiator.java:24)

 ... 78 more

Using the maven-compiler-plugin doesn't seem to make any difference.  I've gone as far as to verify that the jars for alpn-boot, alpn-api, and netty-tcnative were in the WEB-INF/lib directory of the deployed WAR.

I am using OS X El Capitan on a mac, running OpenSSL 1.0.2f.

Day 2 of trying to figure this out... any help would be greatly appreciated!

[Jon Chambers]

To be clear, the ALPN stuff isn't a compile-time dependency; it's a RUNTIME dependency. Adding it as a compiler argument won't help here. What are you using for an application container? You'll need to make sure that the APPLICATION CONTAINER is starting with the special boot classpath arguments. In other words, if you're using Tomcat, you'll need to actually modify the command-line arguments you're passing to Tomcat when you start it. I don't think this is something you can do through the pom; you'll need to do a little surgery on your own to pull this off.

Let me emphasize that we are VERY AWARE that this is a colossal pain, and the larger development community seems to agree. We're looking at the recently-released jetty-alpn-agent (https://github.com/jetty-project/jetty-alpn-agent) to simplify some things, and we're really excited about the statically-linked netty-tcnative builds (see https://github.com/netty/netty-tcnative/pull/113, for example). We'll be working hard to cut down on the confusion in this area.

-Jon

[Ryan Hartzfeld]

Thanks Jon.  I'm running Tomcat 8, and was able to get my application initialized in Eclipse by editing my tomcat server's launch configuration and adding "alpn-boot" as a bootstrap classpath entry.  This got me working in the meantime, but as you're aware, this is a bit unwieldy, particularly in a production environment where you might not have the same level of control.

That said, it seems like you are working hard to get these kinks worked out.  I'll see if there's anywhere I can be of assistance.

Thanks,

Ryan

[Ryan Hartzfeld]

If I try the "Using OpenSSL as an SSL provider" approach with netty-tcnative and alpn-api, can those just be declared as runtime dependencies in the POM and not added to the boot classpath?

[Jon Chambers]

Yes.

-Jon

[Fernando Jordán Silva]

What about using gradle instead of maven? What is the best configuration?

Can pushy be used in a spring boot app? 

-- 
Fernando Jordán Silva

[Jon Chambers]

I'm afraid I don't know much about Gradle; anything we're doing with Maven ought to be possible with Gradle (or even without a build system at all, for that matter), though. What do you mean by "best configuration?"

We're investigating some issues around persistent resource cleanup with Netty (please see https://github.com/relayrides/pushy/issues/245) that might affect Spring Boot depending on the configuration. Everything should work just fine, but it might not be cleaned up as gracefully as we'd like.

-Jon

[Jon Chambers]

Can you be more specific about what's going wrong?

There are some bonus steps you'll want to follow from the netty-tcnative wiki: http://netty.io/wiki/forked-tomcat-native.html. In particular, you'll want to make sure you have the `os-maven-plugin` build extension and make sure you're setting the `os.detection.classifierWithLikes` property.

Hope that helps! If not, though, please let us know what's going wrong.

-Jon

On Thu, Mar 3, 2016 at 5:25 PM, Ryan Hartzfeld <ryan.ha...@gmail.com> wrote:

Still no luck.  I've updated to OpenSSL 1.0.2f (verified with `openssl version`) and my POM looks like this:

<!-- Apple Push Notification Client -->

<dependency>

<groupId>com.relayrides</groupId>

                        <artifactId>pushy</artifactId>

                        <version>0.5.2</version>

                </dependency>

               

                <!-- Pushy system requirements -->

                <dependency>

                        <groupId>io.netty</groupId>

                        <artifactId>netty-tcnative</artifactId>

                        <version>1.1.33.Fork9</version>

                        <classifier>${os.detected.classifier}</classifier>

                </dependency>

                <dependency>

                        <groupId>org.eclipse.jetty.alpn</groupId>

                        <artifactId>alpn-api</artifactId>

                        <version>1.1.2.v20150522</version>

                        <scope>runtime</scope>

                </dependency>

[Ryan Hartzfeld]

Still no luck, still getting the originally mentioned exception.  Updated OSX to use OpenSSL 1.0.2f (double-checked in terminal with `openssl version`).  This is what my POM looks like:

<!-- Apple Push Notification Client -->

<dependency>

<groupId>com.relayrides</groupId>

<artifactId>pushy</artifactId>

<version>0.5.2</version>

</dependency>

<!-- Pushy system requirements -->

<dependency>

<groupId>io.netty</groupId>

<artifactId>netty-all</artifactId>

<version>4.1.0.CR3</version>

</dependency>

<dependency>

<groupId>io.netty</groupId>

<artifactId>netty-tcnative</artifactId>

<version>1.1.33.Fork9</version>

<classifier>${os.detected.classifier}</classifier> <!-- I am using the recommended plugin to determine classifier elsewhere, no issues here -->

</dependency>

<dependency>

<groupId>org.eclipse.jetty.alpn</groupId>

<artifactId>alpn-api</artifactId>

<version>1.1.2.v20150522</version>

<scope>runtime</scope>

</dependency>

It 

[Zhibo Wei]

Same problem here, my application is running standalone, no container, with the following pom:

    <properties>
        <os.detection.classifierWithLikes>fedora</os.detection.classifierWithLikes>
    </properties>
.................

<dependency>
            <groupId>com.relayrides</groupId>
            <artifactId>pushy</artifactId>

            <version>0.6</version>

        </dependency>
        <dependency>
            <groupId>org.eclipse.jetty.alpn</groupId>
            <artifactId>alpn-api</artifactId>
            <version>1.1.2.v20150522</version>
            <scope>runtime</scope>
        </dependency>

        <dependency>
            <groupId>io.netty</groupId>
            <artifactId>netty-tcnative</artifactId>

            <version>1.1.33.Fork15</version>
            <classifier>${os.detected.classifier}</classifier>
        </dependency>
.................
<build>
        <extensions>
            <!-- Use os-maven-plugin to initialize the "os.detected" properties -->
            <extension>
                <groupId>kr.motd.maven</groupId>
                <artifactId>os-maven-plugin</artifactId>
                <version>1.4.0.Final</version>
            </extension>
        </extensions>
........................

Am I doing anything wrong here? Any help would be appreciated.

Zhibo

[Jon Chambers]

For all of you struggling with this: you can ask Netty why it thinks it doesn't have a native SSL provider with the `OpenSsl#unavailabilityCause()` method (see http://netty.io/4.1/api/io/netty/handler/ssl/OpenSsl.html#unavailabilityCause()). Would you mind sharing the stack trace from that exception?

Thanks!

-Jon

[Zhibo Wei]

1919 [main] INFO com.relayrides.pushy.apns.ApnsClient - OpenSSL (via netty-tcnative) not available; will use JDK SSL provider.
Exception in thread "main" java.lang.ExceptionInInitializerError

    at io.netty.handler.ssl.JdkSslContext.toNegotiator(JdkSslContext.java:245)
    at io.netty.handler.ssl.JdkSslClientContext.<init>(JdkSslClientContext.java:263)

    at io.netty.handler.ssl.SslContext.newClientContextInternal(SslContext.java:740)
    at io.netty.handler.ssl.SslContextBuilder.build(SslContextBuilder.java:394)
    at com.relayrides.pushy.apns.ApnsClient.getSslContextWithCertificateAndPrivateKey(ApnsClient.java:358)
    at com.relayrides.pushy.apns.ApnsClient.getSslContextWithP12InputStream(ApnsClient.java:352)
    at com.relayrides.pushy.apns.ApnsClient.getSslContextWithP12File(ApnsClient.java:329)
    at com.relayrides.pushy.apns.ApnsClient.<init>(ApnsClient.java:232)
    at com.relayrides.pushy.apns.ApnsClient.<init>(ApnsClient.java:207)
    at com.xxx.<init>(zzz.java:48)
    at com.xxx(zzz.java:61)
    at com.xxx(ccc.java:28)

Caused by: java.lang.RuntimeException: ALPN unsupported. Is your classpatch configured correctly? See http://www.eclipse.org/jetty/documentation/current/alpn-chapter.html#alpn-starting
    at io.netty.handler.ssl.JdkAlpnApplicationProtocolNegotiator$1.<init>(JdkAlpnApplicationProtocolNegotiator.java:27)
    at io.netty.handler.ssl.JdkAlpnApplicationProtocolNegotiator.<clinit>(JdkAlpnApplicationProtocolNegotiator.java:24)

    ... 12 more

^ Here is the stack trace

[j...@turo.com]

Folks,

I wanted to call your attention to https://groups.google.com/d/msg/pushy-apns/DFuWCwBW5vA/b19hsCzjAgAJ. It sounds like there's an issue that prevents netty-tcnative from working in a Tomcat container due to a classloader conflict. Does it sound like that could be the problem here?

Thanks!

-Jon