JAI 1.3.0のImageIOクラスをロードできません。 Java 6およびWeb Application Server（WAS）8.5。私のコードはJava 6とWAS（7.0.19）でうまく動作しています。WAS 8.5のjavax.imageio.ImageIOクラスをロードできません
私はpomに適切に依存関係を記述しました。誰かが同じ問題を抱えているかどうかを知る必要があります。
byte[] imgBytes = imagesVO.getImgBytes();
BufferedImage image = ImageIO.read(new ByteArrayInputStream(imgBytes));
ので、image値がnull来て、私のサーバーが実行中に可能な負荷のImageIOクラスではないようです。 TIFF形式のファイルをimagesVOに渡しています。
ImageIOライブラリに関するWAS 8.5の動作変更が、そのリリースで追加されたクラスローダのリーク防止ロジックの一部として発生しました。リーク防止機能が有効になっている場合、ImageIOライブラリは、アプリケーションが提供するアプリケーションへのリンク（永続的にはJava EEクラスの読み込みの動的性質に似ていないため、永続的に）を防ぐ目的で、サーバーの起動プロセスの一部として即座にインスタンス化されます実装クラス。しかし、副作用は、アプリケーションクラスが存在する前にライブラリがインスタンス化されているため、アプリケーション提供のプラグインが見つからないということです。
このためのいくつかの潜在的な回避策があります：あなたがあなたの操作を実行する前に
1）が明示的にImageIO.scanForPlugins（）を呼び出します。そうすれば、ImageIOはスレッドコンテキストクラスローダーを使ってプラグインクラスの再スキャンを行い、あなたのものは取得されます。これは、システムレベルのImageIOライブラリからアプリケーションクラスへの永続的な参照を引き起こすので、JVMを再起動せずにアプリケーションを再起動した場合、クラスローダーがリークすることに注意してください（これは以前のWebSphereバージョンで既に発生しています。あなたにとって大きな問題ではありません）。
2）サーバーのクラスローダーリーク防止を無効にします。これは、システム・プロパティー（com.ibm.ws.runtime.component.disableMemoryLeakService = true）を使用して行うことができます。クラスローダのリークについても同様の警告が適用されます。
3）必要なImageIOライブラリをJVMクラスパスに追加します。 JVMレベルのクラスパスの変更を必要とする状況は非常に少なくありますが、これもその1つです。ImageIOはサーバーの起動時にプラグインを検索し、プラグインを見つけます（JVMクラスパスにあるため）。アプリケーションクラスローダがリークすることはありません。