7

アップグレード後、次のエラーが表示されます。

java.lang.VerifyError: (クラス: com/mydomain/server/webservices/OAuth2Utils、メソッド: newFlow 署名: ()Lcom/google/api/client/googleapis/auth/oauth2/GoogleAuthorizationCodeFlow;) 関数への互換性のない引数

これが関連しているかどうかはわかりませんが、私の環境に関する情報:

Linux n53sv 3.2.0-24-generic #38-Ubuntu SMP Tue May 1 16:18:50 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Java バージョン "1.6.0_31" Java(TM) SE ランタイム環境 (ビルド 1.6.0_31- b04) Java HotSpot(TM) 64 ビット サーバー VM (ビルド 20.6-b01、混合モード)

アップデート：

問題を最小限に抑えましたが、本当に信じられないほどです。クラス BadClassTest を作成し、サーブレットで BadClassTest のインスタンスを作成しました。私の BadClassTest がこのように見えるとき:

public class BadClassTest {

    public BadClassTest() {
        com.google.api.client.http.HttpTransport HTTP_TRANSPORT = new com.google.api.client.extensions.appengine.http.urlfetch.UrlFetchTransport();
    }

}

その後、インスタンスを作成できます。

私の BadClassTest がこのように見えるとき:

public class BadClassTest {

    com.google.api.client.http.HttpTransport HTTP_TRANSPORT = new com.google.api.client.extensions.appengine.http.urlfetch.UrlFetchTransport();

    public BadClassTest() {
        //com.google.api.client.http.HttpTransport HTTP_TRANSPORT = new com.google.api.client.extensions.appengine.http.urlfetch.UrlFetchTransport();
    }

}

現在、BadClassTest のインスタンスを作成できません。次の例外が発生します。

java.lang.VerifyError: (クラス: com/klawt/server/BadClassTest、メソッド: 署名: ()V) putfield/putstatic の型が正しくありません

4

2 に答える 2

4

更新（2012年6月6日）：これは、来週初めにクライアントライブラリの次のバージョンで修正される予定です。パッケージの名前をcom.google.api.client.extensions.appengine.http.urlfetchからcom.google.api.client.extensions.appengine.httpに変更するだけです。

元の答え：

問題を特定しました。com.google.api.client.extensions.appengine.http.urlfetch.UrlFetchTransportは、appengine-local-webapis.jarのAppEngineSDKに含まれています。このクラスは実際には誤って存在し、実際にはjar全体が不要です。回避策としての主な推奨事項は、AppEngineSDKのインストールからこのjarファイルを削除することです。ローカルの開発サーバーにのみ読み込まれ、本番AppEngineには読み込まれません。私はまだこれを試していませんが、別のエンジニアがそれが機能するはずだと私に保証します。ぜひお試しいただき、お知らせください。

その回避策が機能しない場合は、App EngineSDK1.6.5にダウングレードしてみてください。appengine-local-webapis.jarは1.6.6の新機能であり、これもローカル開発の問題にすぎません。

最後に、それでも問題が解決しない場合は、komaが推奨するNetHttpTransportに切り替えてください。App Engine HttpURLConnectionの実装（NetHttpTransportが構築されている）には、HTTP応答ヘッダーをコンマで分割するというバグがあります。UrlFetchTransportにはこの問題はありません。ただし、たとえばリダイレクトを処理していて、リダイレクトURLにコンマが含まれている場合を除いて、これがほとんどの開発者に影響を与える可能性はほとんどありません。古いCalendarDataAPIバージョン2（新しいバージョン3ではない）を除いて、どのGoogleAPIでも問題になることはありません。

現在、App Engineチームと協力して、これが次のリリースで修正されることを確認しています。申し訳ありません！

于 2012-06-02T01:47:57.810 に答える
1

この問題に遭遇したgoogle-api-java-client グループの別のユーザーから確認を得ました。回避策は、UrlFetchTransport を削除し、現在 AppEngine でサポートされていると思われる NetHttpTransport を使用することです。

HttpTransport のグローバル インスタンスの実装を、UrlFetchTransport の代わりに NetHttpTransport に置き換え、デプロイして成功しました。

*更新*

Yaniv (google-api-java-client リード) からの回答:

UrlFetchTransport は、引き続き Google App Engine で推奨される選択肢であると考えられています。HTTP ヘッダーの解析に関して、Google App Engine の HttpURLConnection の実装には欠陥がありますが、UrlFetch にはその欠陥はありません。ただし、NetHttpTransport が機能している場合は、引き続き使用できます。

ただし、正直なところ、App Engine 1.6.6 で試したことはありません。1.6.5でのみ試しました。1.6.6 で失敗する原因を調査したいと思います。もう 1 つの可能性は、これが 1.6.6 の新機能ではなく、環境のセットアップ方法が異なることです。

于 2012-05-29T20:54:41.057 に答える