在webapp的亞軍運行Web應用程序的Heroku API調用最終失敗的NoSuchMethodError然後出現NoClassDefFoundError在google.common

Question

我運行在Heroku上使用webapp-runner的戰爭。我通過部署以下命令使用heroku-maven-plugin 1.2版應用程序：mvn heroku:deploy-war。最初，該應用程序可以工作，所有終端都會返回有效的響應。但是，如果我讓該應用足夠長的Heroku把它睡覺，然後調用它調用到番石榴終點閒着我收到NoSuchMethodError：

2017-09-23T19:19:45.388865+00:00 app[web.1]: SEVERE: Servlet.service() for servlet [jersey-serlvet] in context with path [] threw exception [org.glassfish.jersey.server.ContainerException: java.lang.NoSuchMethodError: com.google.common.base.CharMatcher.ascii()Lcom/google/common/base/CharMatcher;] with root cause 
2017-09-23T19:19:45.388866+00:00 app[web.1]: java.lang.NoSuchMethodError: com.google.common.base.CharMatcher.ascii()Lcom/google/common/base/CharMatcher; 
2017-09-23T19:19:45.388867+00:00 app[web.1]: at com.google.common.io.BaseEncoding$Alphabet.<init>(BaseEncoding.java:453) 
2017-09-23T19:19:45.388868+00:00 app[web.1]: at com.google.common.io.BaseEncoding$Base64Encoding.<init>(BaseEncoding.java:892) 
2017-09-23T19:19:45.388869+00:00 app[web.1]: at com.google.common.io.BaseEncoding.<clinit>(BaseEncoding.java:317) 
...application specific stack trace 

的所有後續調用相同的API產生NoClassDefFoundError在同一點

2017-09-23T19:22:24.454901+00:00 app[web.1]: SEVERE: Servlet.service() for servlet [jersey-serlvet] in context with path [] threw exception [org.glassfish.jersey.server.ContainerException: java.lang.NoClassDefFoundError: Could not initialize class com.google.common.io.BaseEncoding] with root cause 
2017-09-23T19:22:24.454903+00:00 app[web.1]: java.lang.NoClassDefFoundError: Could not initialize class com.google.common.io.BaseEncoding 
...application specific stack trace 

這些問題似乎表明，番石榴罐存在於編譯時，但在運行時不存在。不過，我登錄到Web測功機，並驗證了番石榴罐子被列入我warfile

my-mbp:TrickServer me$ heroku ps:exec 
Establishing credentials... done 
Connecting to web.1 on ⬢ myapp... 
~ $ cd target/ 
~/target $ ls 
MyApp.war dependency mvn-dependency-list.log tomcat.52079 
~/target $ jar -tf MyApp.war 
...lots of dependencies... 
WEB-INF/lib/google-oauth-client-1.20.0.jar 
WEB-INF/lib/gson-2.2.4.jar 
WEB-INF/lib/guava-23.0.jar  <---guava 
WEB-INF/lib/guava-jdk5-13.0.jar 
...lots more dependencies... 

我努力解釋爲什麼端點的應用程序部署後立即工作，但後來產生這些錯誤。對我來說，這種行爲似乎表明，Heroku的是可能提供不同的類路徑時，我的應用程序從睡眠狀態時比最初運行醒來或Heroku的移動/清理番石榴jar文件。

我Procfile內容：

web: java $JAVA_OPTS -jar target/dependency/webapp-runner.jar --port $PORT --expand-war target/MyApp.war 

Java進程捉迷藏在我的網頁DYNO：

~/target $ ps -ef | grep java 
u30439  4  1 0 18:50 ?  00:00:44 java -Xmx300m -Xss512k -Dfile.encoding=UTF-8 -Duser.timezone=UTC -jar target/dependency/webapp-runner.jar --port 52079 target/MyApp.war 
u30439  27  4 0 18:50 ?  00:00:00 bash --login -c java $JAVA_OPTS -jar target/dependency/webapp-runner.jar $WEBAPP_RUNNER_OPTS --port 52079 target/MyApp.war 

更新1

因爲我調用我的web應用程序與--expand-war說法我還檢查了擴展目錄中的jar文件以驗證番石榴是否存在。它是：

~/target/tomcat.55320/webapps/expanded/WEB-INF/lib $ ls 
...dependencies... 
google-oauth-client-1.20.0.jar 
gson-2.2.4.jar 
guava-23.0.jar 
guava-jdk5-13.0.jar 
...more dependencies... 

更新2

我添加了以下邏輯有問題的Web服務印出類路徑和它的資源：

logger.info("System Classpath: " + System.getProperty("java.class.path")); 
logger.info("Runtime Classes..."); 
    ClassLoader cl = UserService.class.getClassLoader(); 
    URL[] urls = ((URLClassLoader) cl).getURLs(); 
    for(URL url: urls){ 
     logger.info(url.getFile()); 
    } 

下一次錯誤發生我檢查了日誌，讓我吃驚的發現，番石榴瓶子是出現在運行時類路徑！

2017-09-24T12:07:40.843438+00:00 app[web.1]: [heroku-exec] ERROR: Could not connect to proxy: 
2017-09-24T12:07:40.844145+00:00 app[web.1]: [heroku-exec] ERROR: Too many reconnect attempts. Waiting 30 seconds... 
2017-09-24T12:07:52.671620+00:00 app[web.1]: Sep 24, 2017 12:07:52 PM org.myorg.server.web.services.MyService authenticate 
2017-09-24T12:07:52.671631+00:00 app[web.1]: INFO: System Classpath: target/dependency/webapp-runner.jar 
2017-09-24T12:07:52.671931+00:00 app[web.1]: Sep 24, 2017 12:07:52 PM org.myorg.server.web.services.MyService authenticate 
2017-09-24T12:07:52.671932+00:00 app[web.1]: INFO: Runtime Classes... 
2017-09-24T12:07:52.672277+00:00 app[web.1]: Sep 24, 2017 12:07:52 PM org.myorg.server.web.services.MyService authenticate 
2017-09-24T12:07:52.672279+00:00 app[web.1]: INFO: /app/target/tomcat.28304/webapps/expanded/WEB-INF/classes/ 
.... 
2017-09-24T12:07:52.690304+00:00 app[web.1]: Sep 24, 2017 12:07:52 PM org.myorg.server.web.services.MyService authenticate 
2017-09-24T12:07:52.690306+00:00 app[web.1]: INFO: /app/target/tomcat.28304/webapps/expanded/WEB-INF/lib/google-oauth-client-1.20.0.jar 
2017-09-24T12:07:52.690501+00:00 app[web.1]: Sep 24, 2017 12:07:52 PM org.myorg.server.web.services.MyService authenticate 
2017-09-24T12:07:52.690503+00:00 app[web.1]: INFO: /app/target/tomcat.28304/webapps/expanded/WEB-INF/lib/guava-23.0.jar <--- Guava!!! 
.... 

這是怎麼回事？我該如何調試？

Answer 1

一些調試後，我發現我的計劃有兩個不同版本的番石榴在classpath（guava-23.0.jar & guava-jdk5-13.0.jar）。調試提示建議here是必要的，但還不足以讓我得到這條底線。

使用ClassLoaders時，請務必記住.class對象中定義的getClassLoader方法返回對最初加載該類的ClassLoader的引用。要找到重複的jar，在同一ClassLoader上調用classLoader.getResource("/com/google/common/base/CharMatcher.class")是非常重要的，該ClassLoader加載了後來因NoSuchMethodError失敗的類。

對於後代來說，造成衝突的具體依賴是com.google.api-client。我解決了它通過添加以下exclusion到我的依賴項中pom.xml

<dependency> 
    <groupId>com.google.api-client</groupId> 
    <artifactId>google-api-client</artifactId> 
    <version>1.22.0</version> 
    <exclusions> 
     <exclusion> 
      <groupId>com.google.guava</groupId> 
      <artifactId>guava-jdk5</artifactId> 
     </exclusion> 
    </exclusions> 
</dependency> 

Answer 2

你可能對你的classpath番石榴的兩個版本或與其相關的罐子。見NoSuchMethodError exception when using com.google.common.base.Splitter