オープン ソース ライフサイクル フレームワーク API プロバイダーとして、ライフサイクル API を提供する暗黙の方法で内部設計を非表示にするために最善を尽くしたいと考えています。これにより、API クライアントにより多くの利便性がもたらされます。
コア Java アプリケーションと Java EE アプリケーションの両方の構成を回避することが期待されていますが、現実には、java コマンドの -javaagent:${path}/Lifecycle.jar オプションを使用して、クラスのロード時に独自の ClassFileTransformer を有効にしています。
いくつかの検索の後、いくつかの不明な方向が見つかりました。要約して私たちを導くために、Java Guyが必要です。
- エージェントメインとプリメイン
Glassfish の ByteCodePreprocessor などの特定のランタイム環境との統合には、バイト コード変換を実行する次のメソッドがあります。
public byte[] preprocess(String classname, byte[] classBytes);
これらの方向についての私の混乱:
- Core Java Application の場合、startup クラスの main メソッドを変更して、agentmain ソリューションを適応させることができるようです。他のオプションはありますか?
- Glassfish などの JavaEE Container を使用する場合、ByteCodePreprocessor を使用してクラスのバイト コードを変更できますが、いくつかの新しいクラスを作成する必要がありますが、それらの新しいクラス ファイルをどこに保存するか、または新しいクラス ファイルを設計または適用する方法がわかりません。 ClassLoader を使用して、クラス ファイルの前処理中に新しく作成されたクラス ファイルをロードします。
(ところで、Lifecycle API は、EntityManager インターフェースを持たない JPA に非常に近いメタ駆動型スタイルに従います。現在のところ、それらのほとんどは単なる Annotations と CallbackContext インターフェースと LifecycleEvent インターフェースです。)