0

（Eclipseを使用）

サードパーティが提供するJARのクラスを使用しています。サードパーティのJARには次の行があります。

var = Cipher.getInstance("AES");

この行が実行されると、次のスタックトレースがスローされます。

13:38:00,120 ERROR [stderr] (EJB default - 1) java.lang.ExceptionInInitializerError
13:38:00,121 ERROR [stderr] (EJB default - 1)   at javax.crypto.Cipher.getInstance([DashoPro-V1.2-120198])

...
BLAH BLAH BLAH 
(Stack trace which leads all the way down to the call I make through the third party jar)
...

13:38:00,154 ERROR [stderr] (EJB default - 1) Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
13:38:00,154 ERROR [stderr] (EJB default - 1)   at javax.crypto.b.<clinit>([DashoPro-V1.2-120198])
13:38:00,155 ERROR [stderr] (EJB default - 1)   ... 55 more

以前は、このJARにアクセスするために、Eclipseプロジェクトのフォルダーに貼り付けてから、JARをビルドパスとデプロイメントアセンブリに追加していました。

ただし、2つの異なるデプロイメントでこのサードパーティのjarから初期化されたオブジェクトの同じインスタンスを使用する必要があるため、サードパーティのJARをJBossAS7「モジュール」に移動することが決定されました。

ビルドパス内のプロジェクトでJARへの参照を維持しましたが、デプロイメントアセンブリから削除しました。また、「依存関係：com...[モジュールで指定されたパス]」を追加しました

プロジェクトがビルドおよびデプロイされるため、これは機能したようです。

ただし、すでに数十万回呼び出されているメソッドを呼び出そうとすると、この例外が発生します。

SunJCE_b.classの静的初期化中に例外がスローされているように見えますが、まったくわかりません。

最初のSecurityExceptionがスローされたときのスタックは次のとおりです。

b.e() line: not available   
b.clinit() line: not available  
Cipher.getInstance(String) line: not available  
OtherCompanyCryptography.getCipherInstance() line: not available

オンラインでjavax.crypto.be（）への参照が見つかりません。

以前はこれがどのように機能していましたが、JBossモジュールに変換すると機能しなくなりましたか？

また、どうすればこの問題を解決できますか？

4

2 に答える 2

2

まず、2 つの異なる JVM に関する情報を提供していただきました。

  1. SunJCE_bクラスは Oracle (Sun) JVM からのものです
  2. javax.crypto.bクラスは IBM JVM からのものです

特に彼らは同じことをしています。彼らは、暗号化コンポーネントの署名を検証する責任があります。ほとんどの場合、このようなスタック トレースは、クラス パス上の不適切な管轄ポリシー ファイルが原因で発生します。次に、つまり IBM JVM では、スタック トレースで確認できます。

Caused by: java.lang.SecurityException: Jurisdiction policy files are not signed by trusted signers! 
at javax.crypto.b.a

もう 1 つの理由は、無効な (または古い) 署名を持つ暗号化プロバイダーである可能性があります。より詳細なスタック トレースを提供していただければ、さらにお役に立てます。

于 2013-06-21T18:00:57.567 に答える
0

親愛なる未来の人々:

最終的に使用した回避策は、サード パーティ製の jar を ApiCommons と呼ばれる別のプロジェクトにパッケージ化することでした。

次に、ApplicationBundle.ear という結合アプリケーションを作成しました。

ApplicationBundle.ear には、JNDI を介して 2 つの間で共有される、同じオブジェクトを使用する必要があった 2 つのデプロイメント モジュールが含まれています。

ApplicationBundle プロジェクトには、「配置アセンブリ」に ApiCommons の jar が含まれています。

2 つのデプロイメント モジュールを別々の Eclipse プロジェクトとして保持することができましたが、それらは単一の .EAR ファイルにデプロイされ、バンドルされた両方のプロジェクトのビルド パスには ApiCommons がありますが、デプロイメント アセンブリにはありません。

于 2013-08-20T17:51:17.563 に答える