0

ワーカー JVM を使用してさまざまなことを行うアプリケーション サーバーに取り組んでいます。

ワーカー jvm は、-cp スイッチを使用して開始され、ベンダー ライブラリおよびその他の重要な機能を含む JAR ファイルを指定します。

jarファイルのクラスがコードを適切にロードして実行するという非常に興味深い問題がありますが、jarファイル内のリソースにアクセスしようとすると（特に getResourceAsStream() メソッドを使用して）、見つけられないと主張して爆発します。これらのリソースが、ロードされている JAR に確実に存在することを確認しました。実際、JAR を操作してリソースを外部で検索すると、機能します。問題は、これらはすべて独自のライブラリであり、ソースが付属していないため、逆コンパイルとメソッド エントリ ブレークポイントを通じてすべてを実行する必要があるという点で、私は不自由です。

おそらく最も奇妙な点は、これらのライブラリが何ヶ月も変更されておらず、他の (実稼働を含む) アプリ サーバーで動作していることです。

それらはJRE 1.6.0_17にあります

だから私の質問は

  • -cp エントリを持つ JVM が jar から CLASSES をロードできるのに、RESOURCES をロードできないのはなぜですか?
  • このレルムの何かが JRE 1.6.0_06 から 1.6.0_17 に変更されますか (これは最近変更されました)

明確にするために、JAR 構造では、これらのリソースは jar のルートにあります。

resource.prop
META-INF/Manifest
package/package/class.class

JAR 自体は、ロードされると明らかにクラスパス上にあります。ただし、次のすべてはNULLに解決されます（はい、これは私を狂わせているので、実際に3つすべてを試しました）：

Jarclass.getClassLoader().getResourceAsStream("./resource.prop");
Jarclass.getClassLoader().getResourceAsStream("/resource.prop");
Jarclass.getClassLoader().getResourceAsStream("resource.prop");

これは、すべてのコンピューターで JAR のリソースにアクセスできないのと似ていますが、その質問に対する解決策はありません。

4

2 に答える 2

0

JARのmanifest.mfファイルを調べましたか？これは、JAR内にあるリソースのロードに使用されるクラスパスを制御する最も簡単な方法の1つです。

JARからのリソースの読み取りは、JARのロードに使用されるクラスパスに部分的にのみ関連しています。クラスファイルの場合、JAR内のフォルダ構造は、クラスローダーがクラスをロードするのに十分です。基本的には[CLASSPATH] / [Package]/[Classname]です。

リソースの場合、それは別の問題です。JARのルートはCLASSPATHに追加されますが、子ディレクトリには追加されないため、「resource.prop」がjarのルートにある場合は、提供した3つの例のいずれかが機能します。すでに壺の根元にあるとおっしゃっていたので、謎を深めるだけです。

古いバージョンは機能し、新しいバージョンは機能しないように、JARは何らかの形で変更されましたか？

アプリサーバーのCLASSPATH設定は最近変更されましたか？IBMのWebSphereApplicationServerで問題が発生し、クラスローダーのルールを「最後の親」に設定して（少なくともここでメモリが失敗しない場合）、JVMインスタンスからのクラスパスを最初に使用するようにする必要がありました。次に、IBMが新しいバージョンのWebSphereに含めて開始したものよりも古いlog4j.jarをロードしたため、WebSphereのクラスローダーを使用します。

もう1つのオプションは、JARを展開し、manifest.mfファイルを更新してプロパティへの絶対参照を含めてから、ファイルをカスタムバージョンに再jarすることです。

于 2012-08-14T17:30:29.670 に答える
0

動作していない jar が配置されているディレクトリの名前を確認します。アプリがシンボル!または%その名前でディレクトリにコピーされたときに、同様の問題が発生しました。

于 2012-08-14T17:36:38.807 に答える