1.2. アプリケーションロガーの取得
Red Hat build of Quarkus でアプリケーションロガーを取得するには、次のいずれかの方法を選択します。
1.2.1. ロガーフィールドを宣言する リンクのコピーリンクがクリップボードにコピーされました!
この従来のアプローチでは、特定の API を使用してロガーインスタンスを取得し、それをクラスの静的フィールドに格納し、このインスタンスに対してロギング操作を呼び出します。
サポートされているロギング API であれば、同じフローを適用できます。
JBoss Logging API を使用してロガーインスタンスを静的フィールドに保存する例:
1.2.2. ロギングを簡素化する リンクのコピーリンクがクリップボードにコピーされました!
Quarkus は、io.quarkus.logging.Log を使用するクラスにロガーフィールドを自動的に追加することで、ロギングを簡素化します。これにより、反復的なボイラープレートコードが不要になり、ロギング設定の利便性が向上します。
静的メソッド呼び出しを使用した簡素化されたロギングの例:
- 1
io.quarkus.logging.Logクラスには、JBoss Logging と同じメソッドが含まれます。ただし、それがstaticである点は異なります。- 2
- クラスはロガーフィールドを宣言しないことに注意してください。これは、アプリケーションのビルド中に、
LogAPI を使用する各クラスにprivate static final org.jboss.logging.Loggerフィールドが自動的に作成されるためです。Logメソッドを呼び出すクラスの完全修飾名は、ロガー名として使用されます。この例のロガー名はcom.example.MyServiceです。 - 3
- 最後に、
Logメソッドへの呼び出しはすべて、アプリケーションのビルド中にロガーフィールドに対する通常の JBoss Logging 呼び出しに書き換えられます。
Log API は外部依存関係ではなく、アプリケーションクラスでのみ使用してください。ビルド時に Quarkus によって処理されない Log メソッドを呼び出すと、例外が発生します。
エクステンションでの io.quarkus.logging.Log の使用:
Log API は、アプリケーションクラスでのロギングを簡素化します。一方、拡張モジュールや外部依存関係で使用することは推奨されません。
次の点を考慮してください。
-
io.quarkus.logging.Logは、ビルド時に行われる Quarkus バイトコード変換に依存します。 拡張モジュールでは、モジュールに Jandex インデックスが含まれている場合に限り、
Logが機能します。しかし、この動作はサポートされておらず、ロギングが信頼できないものになる可能性があります。エクステンションの開発では、
io.quarkus.logging.Logの代わりにorg.jboss.logging.Logger.getLogger(String)を使用してください。
1.2.3. 設定されたロガーを注入する リンクのコピーリンクがクリップボードにコピーされました!
@Inject アノテーションを使用して、設定済みの org.jboss.logging.Logger ロガーインスタンスを注入する方法は、アプリケーションアプリケーションロガーを追加する場合の代替手段ですが、これを適用できるのは CDI Bean のみです。
@Inject Logger log を使用すると、ロガーは注入先のクラスにちなんで命名されます。また、@LoggerName("…") Logger log を使用すると、ロガーは指定された名前を受け取ります。
すでに Logger に @LoggerName("…") のアノテーションを付けている場合、@Inject は必要ありません。
注入が完了すると、log オブジェクトを使用してロギングメソッドを呼び出せます。
2 種類のロガーインジェクションの例:
ロガーインスタンスは内部的にキャッシュされます。したがって、たとえば @RequestScoped Bean にロガーが注入されると、挿入されると、ロガーのインスタンス化に関連してパフォーマンスが低下することを回避するために、そのロガーはすべての Bean インスタンスで共有されます。