現在、JavaEE 6 の @PostConstruct メソッドのより複雑な初期化に問題があります。問題が発生する可能性があり、例外が予想される場所がいくつかあります。その場合、半分初期化された Bean が存在する可能性があります。
このような場合、@PreDestroy メソッドが呼び出されますか? そこでリソースを確認し、必要に応じて解放できます。それとも、@PostConstruct ですべての例外をキャッチし、そこにあるすべてのものをクリーンアップする必要がありますか? その仕様は明確ではありません（または、見つけられなかったかもしれません）。
それとも、仕様がないためにベンダー固有のものですか? JBoss 7.x ではどうですか?
この場合、EJB3.1 仕様は明確であると思います。つまり、PostConstruct でアンマネージ リソースを取得した場合、例外が発生した場合はそれらを自分で解放する必要があります。
セクション 14.3.3 - セッション Bean コンテナの PostConstruct および PreDestroy メソッドからの例外 アクション: 例外またはエラーをログに記録します。シングルトンの場合、コンテナで開始されたトランザクションをロールバックします。インスタンスを破棄します。
セクション 14.3.11 - リソースの解放 コンテナーがシステム例外のためにインスタンスを破棄する場合、コンテナーは、エンタープライズ Bean 環境で宣言されたリソース ファクトリを通じて取得された、インスタンスによって保持されているすべてのリソースを解放する必要があります (サブセクション 16.7 を参照)。
注: コンテナーは、インスタンスがエンタープライズ Bean 環境で宣言されたリソース ファクトリを介して取得したリソース マネージャーへの接続を解放する必要がありますが、通常、コンテナーは、インスタンスが JDK API を介して取得した可能性のある「管理されていない」リソースを解放できません。 . たとえば、インスタンスが TCP/IP 接続を開いている場合、ほとんどのコンテナー実装は接続を解放できません。接続は最終的に JVM ガベージ コレクタ メカニズムによって解放されます。
次の 2 つのセクションでは、EJB ビジネス メソッド内または @PostContruct 内で RuntimeException が発生したときに、@PreDestroy メソッドが呼び出されないように指定します。
4.7.3 例外の処理 エンタープライズ Bean クラスの任意のメソッド (コンテナによって呼び出されるビジネス メソッドおよびライフサイクル コールバック インターセプタ メソッドを含む) からスローされるアプリケーション例外ではない RuntimeException は、「存在しない」状態に遷移します。 . 例外処理については、第 14 章で詳しく説明します。Bean クラスに複数のメソッドが適用される場合のライフサイクル コールバック インターセプタ メソッドに関する規則については、セクション 12.5.1 を参照してください。クライアントの観点からは、セッション オブジェクトは引き続き存在します。コンテナーはクライアントの要求を別のインスタンスに委任できるため、クライアントは引き続きセッション オブジェクトにアクセスできます。
12.5.1例外 ライフサイクル コールバック インターセプタ メソッドは、システム ランタイム例外をスローする場合がありますが、アプリケーション例外はスローしません。ライフサイクル インターセプター コールバック メソッドによってスローされた実行時例外により、インターセプター チェーンが巻き戻された後、Bean インスタンスとそのインターセプターが破棄されます [59]。このような例外の結果として Bean とインターセプターが破棄された場合、PreDestroy コールバックは呼び出されません。チェーン内のライフサイクル コールバック インターセプター メソッドは、インターセプター チェーンが巻き戻されるときに必要なクリーンアップ操作を実行する必要があります。