2

java.util.zip.ZipException: 無効な格納ブロック長に遭遇しました。

スタック トレースは次のとおりです。

Caused by: java.util.zip.ZipException: invalid stored block lengths
at java.util.zip.InflaterInputStream.read(Unknown Source)
at java.io.FilterInputStream.read(Unknown Source)
at java.io.FilterInputStream.read(Unknown Source)
at java.util.Properties$LineReader.readLine(Unknown Source)
at java.util.Properties.load0(Unknown Source)
at java.util.Properties.load(Unknown Source)

これは、プロジェクトがアップグレードしようとしたときに発生します。アップグレード ロジックは、古い jar ファイルを新しいものに置き換えることであり、JVM は引き続き実行されます。

jar ファイル (jarA.jar) にはプロパティ ファイルが含まれており、プロパティ ファイルにはいくつかの完全なクラス名が記録されています。これらのクラス名は、リフレクションによってインスタンスを作成するために使用されます。アップグレード ロジックは、SystemClassLoader.getResourceAsStream() を使用してプロパティ ファイルをロードしようとします。

jar ファイル (jarA.jar) を新しいものに置き換え、プロパティの内容を変更すると、この例外が発生します。SystemClassLoader がプロパティを正しくロードできないようです。

プロジェクトは java1.4 でコンパイルされ、jre1.7 で実行され、OS は Windows です。

プロパティが存在するときに SystemClassLoader がロードに失敗した理由を説明できる人はいますか? 私はあなたの助けに感謝します。

4

3 に答える 3

1

jar ファイルを置き換えた後に getResourceAsStream(String) を使用する場合は、独自のメソッド ClassLoader.findResource(String) を実装するだけです。

public URL findResource(final String name) {
    // find URL (and cache it if necessary (Hashtable ?))
    // do not call super.findResource(String)
    return url; // in a jar: new URL("jar:jar-path!/" + name);
}

これにより、リソースの適切なリロードが保証されます (jar 内であっても)。

(まだ正確にはわかりませんが、デフォルトのクラスローダーは最初に見つかった URL への接続を保存しているように見えます。これはソースを置き換えた後に無効になりますが、クラスを担当するクラスローダーでは変更されません)

于 2013-06-12T15:26:16.297 に答える