Fat JARからのIronPdfEngine接続障害
IronPDF for Javaアプリケーションがfat (uber) JARとしてパッケージ化されている場合、クライアントは内部レンダリングエンジンに接続できません。IronPdfEngineは正しいポートで起動して傾聴しますが、Javaクライアントは20回の接続試行を行っても毎回失敗します。
Failed to connect to IronPdfEngine after 20 attempts
すべての依存関係を単一の自己組み立てシャーデッド (uber) JARにマージすることで障害が発生します。例として、Maven ShadeやGradle Shadowプラグインが考えられます。 マージされた依存関係からの重複したリソースファイルによってJavaクライアントがIronPdfEngineサブプロセスに到達するのを妨げます:エンジンは起動して予想されるポートを開きますが、クライアントは20回試行しても接続できず諦めます。 各依存関係をクラスパス上で個別のファイルとして保持することで、問題を回避できます。
解決策
プロジェクトを通常通りビルドし、その依存関係をフォルダーにコピーして、java -jarを使用せずにJavaでそれらのファイルを直接参照してアプリを起動します。
1. プロジェクトをビルド
mvn clean package
2. ランタイム依存関係をコピー
target/libsにそれぞれのライブラリを個別のJARとして配置します。これはクラスパスアプローチで必要なことです。
mvn dependency:copy-dependencies -DoutputDirectory=target/libs
3. クラスパスから実行
fat JARではなく展開されたクラスパスに対してアプリを起動します。 実際のメインクラスにcom.example.Mainを置き換えます。
Windows:
java --add-opens java.base/java.nio=ALL-UNNAMED -cp "target/classes;target/libs/*" com.example.Main
Linux / macOS:
java --add-opens java.base/java.nio=ALL-UNNAMED -cp "target/classes:target/libs/*" com.example.Main
2つのコマンドの唯一の違いはクラスパスの区切り文字です:Windowsではセミコロン(:)です。
デバッグのヒント
- 動作しない: fat JARから実行すると
IronPdfEngineは正常に起動しますが、Javaクライアントは決して接続しません。 --add-opensだけでは不十分です: JVMフラグを追加しても、fat JARから実行し続ける限り接続障害は解消されません。 このフラグは上記のクラスパス起動と共にのみ重要です。- PDF/Aバージョン文字列: コードがPDF/Aバージョンを文字列引数として渡す場合、
PdfAVersions.PdfA2aは使用しません。

Curtis Chauは、カールトン大学でコンピュータサイエンスの学士号を取得し、Node.js、TypeScript、JavaScript、およびReactに精通したフロントエンド開発を専門としています。直感的で美しいユーザーインターフェースを作成することに情熱を持ち、Curtisは現代のフレームワークを用いた開発や、構造の良い視覚的に魅力的なマニュアルの作成を楽しんでいます。