問題タブ [jsr311]

この問題についてよく検索し、3 日以上費やしましたが、どのスレッドも役に立ちませんでした。Jersey oAuth を使用して Web サービスにアクセスしています。

以下はジャージoAuthの私のコードです。

}

oAuth の場合、以下の API を使用しています。

1. リスト項目
2. OAuth クライアント 1.12.jar
3. OauthSignature-1.12 jar
4. ジャージー クライアント -1.12 jar
5. jersey-core-1.12.jar
6. jersey-json-1.12.jar
7. jsr311.jar

このコードを単純なJavaアプリケーションで実行すると正常に動作しますが、このコードをJavaからAndroidに移行すると、エラーが発生し始めます

[2014-09-27 17:19:05 - Dex Loader] dex を実行できません: 複数の dex ファイルで Ljavax/ws/rs/ApplicationPath が定義されています。[2014-09-27 17:19:05 - Demo-Jersey] Dalvik 形式への変換に失敗しました: dex を実行できません: 複数の dex ファイルで Ljavax/ws/rs/ApplicationPath が定義されています。

私はそれについてグーグルで調べました.いくつかのスレッドは、jsr311からApplicationPathファイルを削除することを提案しています. 私は同じことをしましたが、それでも問題を解決できませんでした。

誰でもこの問題を取り除く方法を知っていますか? このコードが Android ではなく Java で動作するのはなぜですか?

コードで使用できる Android 固有の jsr311 はありますか?

誰かが解決策を持っている場合は親切に助けてください。

最近まで、私のコードは GAE と開発サーバーで正常に動作していました。その後、最近、新しいバージョンをアップロードしましたが、サーバーではまったく機能せず、ローカル マシン (開発サーバー) では問題なく機能します。古いバージョンは引き続きサーバー上で動作します。

新しいバージョンの URL にアクセスするたびに、次のストラックトレースがログに記録されます。

これは、私が見つけることができる最も関連性の高い依存関係です (プロジェクトで使用しているユーティリティ ライブラリにあります)。

確かに、その中のクラスにはメソッドjavax.ws.rs.core.Applicationが含まれていません。getProperties()

問題は、このコードが開発サーバーでなぜ/どのように機能するのかということです。

このライブラリや、コードの全体的なレイアウトや動作に影響を与える最近の変更は行っていません (既存のコードにいくつかの機能を追加しただけです)。この問題の原因は何ですか?

GAE Java SDK のバージョン 1.9.32 を使用していて、最近 1.9.34 にアップグレードしました -- その後、問題が発生しました (ただし、1.9.32 に戻しても問題は解決しませんでした)。Cloud Platform コンソールは、SDK バージョン 1.9.35 を示します。

必死になって私は試しました：

• クリーン＆リビルド（ライブラリプロジェクトにも依存）、
• GAE で新しいバージョンを削除して再アップロードする
• 別のバージョン番号でコードを再アップロードする

からのバージョンpom.xml:

(1～2本抜けてるかも)

Jersey-bundleをjsr311-apiに置き換えようとしていますが、 pom.xmlで置き換えた後、java.lang.CLassNotFoundException com.sun.ws.rs.ext.runtimedelegateimplを取得しています

少しデバッグすると、jsr311-api.javax.ws.rs.ext.RunTimeDelegate.findDelegate()で最初にjavax.ws.rs.ext.RunTimeDelegateが検索され、次にcom.sun.ws.rsが検索されることがわかりました。 ext.runtimedelegateimpl。そもそもjavax.ws.rs.ext.RunTimeDelegateに資金を提供できないのはなぜですか? そして明らかに私はそれについて泣いているruntimedelegateimplを持っていません。jersey-bundleをjsr311-apiに完全に置き換えることは可能ですか、それとも jesey-bundleをjsrと一緒に保持する必要がありますか?

MessageBodyReader処理中にリクエスト URI に対して URI を解決する必要があるカスタムを実装しています。MessageBodyReaderが JAX-RSサーバー実装で使用されている場合。UriInfo着信 POST リクエストを処理します。実行時に挿入されるオブジェクトからリクエスト URI を取得できます@Context(たとえばhttps://stackoverflow.com/a/3314076で説明されているように):

MessageBodyReaderのエンティティの読み取り中にが JAX-RSクライアント実装で呼び出された場合Response、インジェクションは発生しませんNullPointerException。

URIを解決する目的で、私の質問は次のとおりです。

が JAX-RSクライアント実装で呼び出されreadFrom(...)た場合、リクエスト URI を見つけるにはどうすればよいですか?MessageBodyReader

現在の回避策: Jersey ドキュメントの10.4 章「フィルターとインターセプターの実行順序」を読んだ後、ステップ 16 でClientResponseFilter、要求 URI と応答ヘッダーの両方にアクセスできることがわかりました。したがってClientResponseFilter、リクエスト URI をカスタム レスポンス ヘッダーに入れる を作成しました。次に、そのカスタム ヘッダーを の 5 番目のパラメーターから取得できますreadFrom(...)。