初期化時の設定
ログ リクエストをアプリケーション コードに挿入するには、かなりの計画と労力が必要です。観察によると、コードの約 4% がログ記録専用であることがわかります。その結果、中程度の規模のアプリケーションであっても、コード内に数千のログ ステートメントが埋め込まれます。その数を考慮すると、これらのログ ステートメントを管理するツールが必要です。
Logback は、プログラムで構成することも、XML、Groovy、シリアル化されたモデル形式で表現された構成スクリプトを使用して構成することもできます。ちなみに、既存の log4j ユーザーは、PropertiesTranslator Web アプリケーションを使用して、log4j.properties ファイルを logback.xml に変換できます。
ログ リクエストをアプリケーション コードに挿入するには、かなりの計画と労力が必要です。観察によると、コードの約 4% がログ記録専用であることがわかります。したがって、中程度の規模のアプリケーションでも、コード内に数千のログ ステートメントが含まれる可能性があります。その量を考えると、これらのログ ステートメントを管理するツールが必要です。
Logback は、プログラムで構成することも、XML、Groovy、またはシリアル化されたモデル形式で表現された構成スクリプトを使用して構成することもできます。ちなみに、既存の log4j ユーザーは、PropertiesTranslator Web アプリケーションを使用して、log4j.properties ファイルを logback.xml に変換できます。
まず、logback が自身を構成するために実行する初期化手順について説明します。
Logback は、サービス プロバイダーの読み込み機能を使用してカスタム Configurator プロバイダーを検索します。このようなカスタム プロバイダーが
見つかった場合は、logback 独自のコンフィギュレーター (例: DefaultJoranConfigurator) よりも優先されます
(以下を参照)。カスタム コンフィギュレータは、
ch.qos.logback.classic.spi.Configurator インターフェイスの実装です。カスタム コンフィギュレータは、META-INF/services/ch.qos.logback.classic.spi.Configuratorの下にある
ファイル リソースを検索することによって検索されます。このファイルの内容では、目的の Configurator 実装の完全修飾クラス名を指定する必要があります。
SINCE 1.3.9/1.4.9前の手順でユーザー指定のカスタム コンフィギュレーターが見つからなかった場合、logback は
SerializedModelConfigurator をインスタンス化します。
• システム プロパティ「logback.serializedModelFile」が設定されている場合、
SerializedModelConfigurator は前述のシステム プロパティで指定されたファイルを見つけようとします
。指定されたファイルが見つかると
、設定のためにそのファイルが読み取られて解釈されます。
• 前述のシステム プロパティが設定されていない場合、または
指定されたファイルが見つからない場合、SerializedModelConfigurator はクラスパス内で
シリアル化された構成モデル ファイル logback-test.scmo を検索します。
このファイルが見つかると、ファイルが読み取られて、
構成のために解釈されます。
• 前述のファイルが見つからない場合、 SerializedModelConfigurator はクラスパス内で
シリアル化された構成モデル ファイル logback.scmo を検索します。• シリアル化された構成モデル ファイルが見つからない場合、 SerializedModelConfigurator は、次に使用可能なコンフィギュレータ (例: DefaultJoranConfigurator) の呼び出しを求める実行ステータスを返します。シリアル化されたモデル ファイルからの構成はより高速に実行され、XML ライブラリは必要ありません。GraalVM と併用すると、より高速に起動する、より小さな実行可能ファイルが生成される可能性があります。- 通常のステップ 以前のコンフィギュレータが必要なリソースを見つけられなかった場合
、DefaultJoranConfigurator のインスタンスが
作成され、呼び出されます。
• システム プロパティ「logback.configurationFile」が設定されている場合、
DefaultJoranConfigurator は前述のシステム プロパティで指定されたファイルを見つけようとします
。このファイルが見つかると、
構成のために読み取られて解釈されます。• 前の手順が失敗した場合、DefaultJoranConfigurator はクラスパス上で設定ファイル「logback-test.xml」を見つけようと
します。このファイルが見つかると、構成のために読み取られて解釈されます。• そのようなファイルが見つからない場合は、設定を見つけようとします。
クラスパス内のファイル「logback.xml」。このファイルが見つかると、
構成のために読み取られて解釈されます。これは名目上の構成ステップであることに注意してください
。
• 設定ファイルが見つからない場合、 DefaultJoranConfigurator は、次に使用可能なコンフィギュレータ、つまり BasicConfigurator の呼び出しを求める
実行ステータスを返します。
上記のいずれも成功しない場合、logback-classic は BasicConfigurator を使用して自身を構成し、ログ出力がコンソールに送信されます。
2. 1.3.9 および 1.4.9 からは追加の SerializedModelConfigurator が存在します。
上位バージョンの logback 1.4.9 にはそれが含まれていますが、以前のバージョン 1.2.4 には Serialized ModelConfigurator クラスと defaultjoran クラスが含まれていないことに注意してください。
ログバックの自動構成
ログバックを構成する最も簡単な方法は、ログバックをデフォルト構成にフォールバックさせることです。
MyApp1 という架空のアプリケーションでこれがどのように行われるかを試してみましょう
。
package chapters.configuration;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class MyApp1 {
final static Logger logger = LoggerFactory.getLogger(MyApp1.class);
public static void main(String[] args) {
logger.info("Entering application.");
Foo foo = new Foo();
foo.doIt();
logger.info("Exiting application.");
}
}
(logback-examples/src/main/java/chapters/configuration/Foo.java)
package chapters.configuration;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class Foo {
static final Logger logger = LoggerFactory.getLogger(Foo.class);
public void doIt() {
logger.debug("Did it again!");
}
}
pomインポートjar
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>${logback.version}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>2.0.7</version>
</dependency>
印刷結果
17:18:04.095 [main] INFO com.chenchi.log.chapter3.MyApp1 -- Entering application.
17:18:04.108 [main] DEBUG com.chenchi.log.chapter3.Foo -- Did it again!
17:18:04.108 [main] INFO com.chenchi.log.chapter3.MyApp1 -- Exiting application.
構成ファイル logback-test.xml または logback.xml が存在しないと仮定すると、logback はデフォルトで BasicConfigurator を呼び出し、最小限の構成をセットアップします。この最小限の構成は、ルート ロガーに接続された ConsoleAppender で構成されます。出力は、パターン %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} -%kvp- %msg%n に設定された PatternLayoutEncoder を使用してフォーマットされます。さらに、デフォルトでは、ルート ロガーには DEBUG レベルが割り当てられます。
構成ファイル logback-test.xml または logback.xml が存在しないと仮定すると、logback はデフォルトで BasicConfigurator を呼び出し、最小構成を設定します。この最小構成には、ルート ロガーに接続するコンソール接続が含まれます。出力は、パターン %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} -%kvp- %msg%n に設定された PatternLayoutEncoder を使用してフォーマットされます。さらに、デフォルトでは、ルート ロガーには DEBUG レベルが割り当てられます。
アペンダーのレイアウトとレベルは 3 つのセクションにそれぞれ設定されます。
logback-test.xml または logback.xml による構成
(logback-examples/src/main/resources/chapters/configuration/sample0.xml)
<configuration>
<!-- STDOUT 这个是appendername 可以随便取 sout print啥都行-->
<!-- ch.qos.logback.core.ConsoleAppender 是具体的类 一般用自带的 也可以自定义-->
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<!-- encoders are assigned the type
ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} -%kvp- %msg%n</pattern>
</encoder>
</appender>
<root level="debug">
<appender-ref ref="STDOUT" />
</root>
</configuration>
Sample0.xml の名前を logback.xml (または logback-test.xml) に変更した後、それをクラス パスからアクセスできるディレクトリに配置します。MyApp1 アプリケーションを実行すると、前回の実行と同じ結果が得られます。logback.xml または Put の名前を変更しました
。クラスパス上の logback-test.xml を参照し、再度実行します。
警告またはエラーが発生した場合のステータスメッセージの自動印刷
構成ファイルの解析中に警告またはエラーが発生した場合、logback は内部ステータス メッセージをコンソールに自動的に出力します。
public static void main(String[] args) {
// assume SLF4J is bound to logback in the current environment
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
// print logback's internal status
StatusPrinter.print(lc);
...
}
ログを印刷する
17:29:25.146 [main] INFO [com.chenchi.log.chapter3.MyApp2] [-]- Entering application.
17:29:25.160 [main] DEBUG [com.chenchi.log.chapter3.Foo] [-]- Did it again!
17:29:25.160 [main] INFO [com.chenchi.log.chapter3.MyApp2] [-]- Exiting application.
17:29:24,747 |-INFO in ch.qos.logback.classic.LoggerContext[default] - This is logback-classic version 1.3.9
17:29:24,751 |-INFO in ch.qos.logback.classic.util.ContextInitializer@617faa95 - No custom configurators were discovered as a service.
17:29:24,751 |-INFO in ch.qos.logback.classic.util.ContextInitializer@617faa95 - Trying to configure with ch.qos.logback.classic.joran.SerializedModelConfigurator
17:29:24,752 |-INFO in ch.qos.logback.classic.util.ContextInitializer@617faa95 - Constructed configurator of type class ch.qos.logback.classic.joran.SerializedModelConfigurator
17:29:24,761 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.scmo]
17:29:24,761 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.scmo]
17:29:24,762 |-INFO in ch.qos.logback.classic.util.ContextInitializer@617faa95 - ch.qos.logback.classic.joran.SerializedModelConfigurator.configure() call lasted 10 milliseconds. ExecutionStatus=INVOKE_NEXT_IF_ANY
17:29:24,762 |-INFO in ch.qos.logback.classic.util.ContextInitializer@617faa95 - Trying to configure with ch.qos.logback.classic.util.DefaultJoranConfigurator
17:29:24,763 |-INFO in ch.qos.logback.classic.util.ContextInitializer@617faa95 - Constructed configurator of type class ch.qos.logback.classic.util.DefaultJoranConfigurator
17:29:24,763 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback-test.xml] at [file:/D:/install/code/learning/bigdata_learining/log/logback/target/classes/logback-test.xml]
17:29:25,054 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - Processing appender named [STDOUT]
17:29:25,054 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
17:29:25,063 |-INFO in ch.qos.logback.core.model.processor.ImplicitModelHandler - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
17:29:25,119 |-INFO in ch.qos.logback.classic.model.processor.RootLoggerModelHandler - Setting level of ROOT logger to DEBUG
17:29:25,119 |-INFO in ch.qos.logback.core.model.processor.AppenderRefModelHandler - Attaching appender named [STDOUT] to Logger[ROOT]
17:29:25,119 |-INFO in ch.qos.logback.core.model.processor.DefaultProcessor@1e127982 - End of configuration.
17:29:25,120 |-INFO in ch.qos.logback.classic.joran.JoranConfigurator@60c6f5b - Registering current configuration as safe fallback point
17:29:25,120 |-INFO in ch.qos.logback.classic.util.ContextInitializer@617faa95 - ch.qos.logback.classic.util.DefaultJoranConfigurator.configure() call lasted 357 milliseconds. ExecutionStatus=DO_NOT_INVOKE_NEXT_IF_ANY
これは、さまざまなログ jar の競合が発生し、どこで競合が発生しているかわからない場合や、さまざまなログ構成ファイルの XML プロパティが多数あり、どれが機能するかわからない場合に適しています。カーネル情報をすばやく出力することができます。それを見つけてください。
ステータスデータ
ステータス データの出力を有効にすると、ログバックの問題
(logback-examples/src/main/resources/chapters/configuration/onConsoleStatusListener.xml)
ステータス データを診断するのに非常に役立ちます。これは、印刷コンテキスト
を強制的に
LoggerContext lc = ( LoggerContext) LoggerFactory. getILoggerFactory();
// ログバックの内部ステータスを出力します
StatusPrinter.print(lc);
変更時に構成ファイルを自動的に再ロードする
これは、更新された構成ファイルを自動的にロードする場合に便利です。
<configuration scan="true" scanPeriod="30 seconds" >
...
</configuration>
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class MyAppScan {
final static Logger logger = LoggerFactory.getLogger(MyAppScan.class);
public static void main(String[] args) throws InterruptedException {
MyAppScan myAppScan = new MyAppScan();
while (true){
myAppScan.printAll();
Thread.sleep(10000);
}
}
private void printAll(){
logger.trace("trace");
logger.debug("debug");
logger.info("info");
logger.warn("warn");
logger.error("error");
System.out.println("==============================");
}
}
ログバック.xml
<configuration scan="true" scanPeriod="15 seconds" >
<!-- STDOUT 这个是appendername 可以随便取 sout print啥都行-->
<!-- ch.qos.logback.core.ConsoleAppender 是具体的类 一般用自带的 也可以自定义-->
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<!-- encoders are assigned the type
ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level [%logger{36}] [-%kvp]- %msg%n</pattern>
</encoder>
</appender>
<!-- status data 这个就是强行打印 context-->
<statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" />
<root level="error">
<appender-ref ref="STDOUT" />
</root>
</configuration>
リソースが時間内にコンパイルされない可能性があるため、テストする場合は、ターゲット/クラスの下の XML ファイルを変更する必要があることに注意してください。
スタック トレースでのデータのパッケージ化の有効化
指示があれば、logback は出力するスタック トレース行の各行にパックされたデータを含めることができます。パッケージ化データは、スタック トレース行のクラスのソースである jar ファイルの名前とバージョンで構成されます。パッケージ化データは、ソフトウェアのバージョン管理の問題を特定するのに役立ちます。ただし、特に頻繁に例外をスローするアプリケーションでは、計算コストが非常に高くなります。
設定方法
<configuration packagingData="true">
...
</configuration>
または
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
lc.setPackagingDataEnabled(true);
突然ですが、何の異常を見つければいいのか分かりませんが、ログの出力がより充実したような気がするのですが？
JoranConfigurator を直接呼び出す
(logback-examples/src/main/java/chapters/configuration/MyApp3.java)
用途がわかりません
logback-classic の停止
リソースをリリースする
import org.sflf4j.LoggerFactory;
import ch.qos.logback.classic.LoggerContext;
...
// assume SLF4J is bound to logback-classic in the current environment
LoggerContext loggerContext = (LoggerContext) LoggerFactory.getILoggerFactory();
loggerContext.stop();
シャットダウンフックによるlogback-classicの停止
JVM シャットダウン フックのインストールは、ログバックをシャットダウンし、関連するリソースを解放するための便利な方法です。
<configuration debug="true">
<!-- in the absence of the class attribute, assume
ch.qos.logback.core.hook.DefaultShutdownHook -->
<shutdownHook/>
<!-- rest of the config file.. -->
</configuration>
設定ファイルの構文
タグ名の大文字と小文字の区別
特定のタグ名にどの大文字と小文字を使用するかがわからない場合は、ほとんどの場合正しい規則であるキャメルケース規則に従ってください
。
ロガーまたは要素の構成
<configuration>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>
%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} -%kvp- %msg%n
</pattern>
</encoder>
</appender>
<logger name="chapters.configuration" level="INFO" />
<logger name="chapters.configuration.Foo" level="DEBUG" />
<root level="DEBUG">
<appender-ref ref="STDOUT" />
</root>
</configuration>
これは先ほど述べたレベル継承アペンダーですが、実は継承も可能です。
<configuration>
<appender name="STDOUT"
class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>
%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} -%kvp- %msg%n
</pattern>
</encoder>
</appender>
<logger name="chapters.configuration" level="INFO" />
<!-- turn OFF all logging (children can override) -->
<root level="OFF">
<appender-ref ref="STDOUT" />
</root>
</configuration>
アペンダーの構成
アペンダは、2 つの必須属性の名前とクラスを取る要素で構成されます。name 属性はアペンダーの名前を指定し、class 属性はインスタンス化するアペンダー クラスの完全修飾名を指定します。要素には、0 個または 1 個の要素、0 個以上の要素、および 0 個以上の要素が含まれる場合があります。これら 3 つの共通要素とは別に、要素には、アペンダー クラスの JavaBean プロパティに対応する要素を任意の数だけ含めることができます。後の章で説明するように、特定のログバック コンポーネントのプロパティをシームレスにサポートすることは、Joran の大きな強みの 1 つです。次の図は、一般的な構造を示しています。以下の図にはプロパティのサポートが示されていないことに注意してください。
アペンダーは <appender> 要素で構成されます。この要素には、名前とクラスという 2 つの必須属性があります。name 属性はアペンダーの名前を指定し、
class 属性はインスタンス化するアペンダー クラスの絶対パス名を指定します。
<appender> 要素には、0 個以上の <layout> 要素、0 個以上の <encoder> 要素、および 0 個以上の <filter> 要素を含めることができます。これら 3 つの共通要素に加えて、 <appender> 要素には、アペンダー クラスの JavaBean プロパティに対応する要素を任意の数だけ含めることができます。特定のログバック コンポーネントのプロパティをシームレスにサポートすることは、Joran の主な強みの 1 つであり、後の章で説明します。以下の図は、一般的な構造を示しています。以下の図にはプロパティのサポートが示されていないことに注意してください。
<configuration>
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>myApp.log</file>
<encoder>
<pattern>%date %level [%thread] %logger{10} [%file:%line] -%kvp- %msg%n</pattern>
</encoder>
</appender>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%kvp %msg%n</pattern>
</encoder>
</appender>
<root level="debug">
<appender-ref ref="FILE" />
<appender-ref ref="STDOUT" />
</root>
</configuration>
これらの構成スクリプトは、FILE と STDOUT という名前の 2 つのアペンダーを定義します。
FILE アペンダは、myApp.log という名前のファイルにログを記録します。エンコーダーは PatternLayoutEncoder で、日付、レベル、スレッド名、ロガー名、ファイル名、ログ リクエストの行番号、メッセージ、行区切り文字を出力します。
STDOUT という名前の 2 番目のアペンダーは、コンソールに出力します。このアドオンのエンコーダーは、メッセージ文字列とその後に続く行区切り文字のみを出力します。
アペンダーが蓄積する
<configuration>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} -%kvp- %msg%n</pattern>
</encoder>
</appender>
<logger name="chapters.configuration">
<appender-ref ref="STDOUT" />
</logger>
<root level="debug">
<appender-ref ref="STDOUT" />
</root>
</configuration>
Chapters.configuration はルートを継承し、標準出力があり、別の出力を追加するため、ログが繰り返されます。
実際、ここで継承しないことを選択することもできます。
以下のデモには、
デフォルトの累積動作をオーバーライドする
<configuration>
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>foo.log</file>
<encoder>
<pattern>%date %level [%thread] %logger{10} [%file : %line] -%kvp- %msg%n</pattern>
</encoder>
</appender>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%msg%n</pattern>
</encoder>
</appender>
<logger name="chapters.configuration.Foo" additivity="false">
<appender-ref ref="FILE" />
</logger>
<root level="debug">
<appender-ref ref="STDOUT" />
</root>
</configuration>
この例では、FILE という名前のアペンダーが Chapters.configuration.Foo ロガーにアタッチされています。さらに、chapters.configuration.Foo ロガーの加法性フラグは false に設定されており、ロギング出力は FILE という名前のアペンダーには送信されますが、階層の上位に接続されているアペンダーには送信されません。他のロガーは、chapters.configuration.Foo ロガーの加法性設定を意識しません。additivityFlag.xml 構成ファイルを使用して MyApp3 アプリケーションを実行すると、chapters.configuration.MyApp3 ロガーからの結果がコンソールに出力されます。ただし、chapters.configuration.Foo ロガーからの出力は、foo.log ファイルにのみ表示されます。
Chapters.configuration.Foo 只有ファイルアペンダー 没有stdout
変数置換
このドキュメントの以前のバージョンでは、「変数」という用語の代わりに「プロパティ置換」という用語が使用されていました。これら 2 つの用語は互換性があると考えてください。ただし、後者の用語はより具体的な意味を表します。
多くのスクリプト言語と同様、ログバック構成ファイルは変数の定義と置換をサポートします。変数にはスコープがあります (以下を参照)。さらに、変数は構成ファイル自体、外部ファイル、外部リソースで定義でき、動的に計算および定義することもできます。
変数の置換は、値を指定できる構成ファイル内のどこでも実行できます。変数置換の構文は、Unix シェルの構文と似ています。先頭の{ と末尾 }の間の文字列は、属性値への参照として解釈されます。属性 a Name の場合、 { と末尾 } の間の文字列 " は、属性値への参照として解釈されます。属性 aName の場合、文字列 "{ と末尾 } の間の文字列は、属性値への参照として解釈されます。属性a N am eの場合、文字列「 {aName}」は、 aName 属性が保持する値に置き換えられます。
HOSTNAME 変数と CONTEXT_NAME 変数は、自動的に定義され、コンテキスト スコープを備えているため、多くの場合便利です。環境によってはホスト名の計算に時間がかかることを考慮して、その値は (必要な場合にのみ) 遅延計算されます。さらに、HOSTNAME は構成から直接設定できます。
変数の定義
＜変数＞＜プロパティ＞で変数を定義可能
デモ1
<configuration>
<variable name="USER_HOME" value="/home/sebastien" />
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>${USER_HOME}/myApp.log</file>
<encoder>
<pattern>%kvp %msg%n</pattern>
</encoder>
</appender>
<root level="debug">
<appender-ref ref="FILE" />
</root>
</configuration>
デモ2
<configuration>
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>${USER_HOME}/myApp.log</file>
<encoder>
<pattern>%kvp %msg%n</pattern>
</encoder>
</appender>
<root level="debug">
<appender-ref ref="FILE" />
</root>
</configuration>
java -DUSER_HOME="/home/sebastien" MyApp2
デモ3
<configuration>
<variable file="src/main/java/chapters/configuration/variables1.properties" />
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>${USER_HOME}/myApp.log</file>
<encoder>
<pattern>%kvp %msg%n</pattern>
</encoder>
</appender>
<root level="debug">
<appender-ref ref="FILE" />
</root>
</configuration>
logback-examples/src/main/resources/chapters/configuration/variables1.properties
USER_HOME=/ホーム/セバスチャン
デモ4
ファイルの代わりにクラスパス上のリソースを参照することもできます。
<configuration>
<variable resource="resource1.properties" />
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>${USER_HOME}/myApp.log</file>
<encoder>
<pattern>%kvp %msg%n</pattern>
</encoder>
</appender>
<root level="debug">
<appender-ref ref="FILE" />
</root>
</configuration>
スコープ
プロパティは、ローカル スコープ、コンテキスト スコープ、またはシステム スコープに挿入するように定義できます。ローカル スコープがデフォルトです。OS環境から変数を読み込むことは可能ですが、OS環境に書き込むことはできません。
ローカル スコープ ローカル スコープを持つプロパティは、設定ファイル内でのその定義の時点から、その設定ファイルの解釈/実行の終了まで存在します。その結果、構成ファイルが解析されて実行されるたびに、ローカル スコープの変数が新たに定義されます。
コンテキスト スコープ コンテキスト スコープを持つプロパティはコンテキストに挿入され、コンテキストが存続するか、コンテキストがクリアされるまで存続します。定義されると、コンテキスト スコープ内のプロパティはコンテキストの一部になります。そのため、シリアル化を通じてリモート ホストに送信されるイベントを含む、すべてのログ イベントで利用できます。
システム スコープ システム スコープを持つプロパティは、JVM のシステム プロパティに挿入され、JVM が存在する限り、またはクリアされるまで存続します。
デモ1
<configuration>
<variable scope="context" name="nodeId" value="firstNode" />
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>/opt/${nodeId}/myApp.log</file>
<encoder>
<pattern>%kvp %msg%n</pattern>
</encoder>
</appender>
<root level="debug">
<appender-ref ref="FILE" />
</root>
</configuration>
上記の例では、nodeId 属性がコンテキスト スコープで定義されていると仮定すると、シリアル化を通じてリモート ホストに送信されたイベントも含め、すべてのロギング イベントでこの属性を使用できます。
変数のデフォルト値
特定の状況では、変数が宣言されていない場合、またはその値が null の場合、変数にデフォルト値があることが望ましい場合があります。Bash シェルと同様に、「:-」演算子を使用してデフォルト値を指定できます。たとえば、aName という名前の変数が定義されていないとすると、「${aName:-golden}」は「golden」として解釈されます。
場合によっては、変数が宣言されていない場合、またはその値が null の場合に、変数にデフォルト値を持たせたい場合があります。Bashshell と同様に、「:-」演算子を使用してデフォルト値を指定できます。たとえば、aName という名前の変数が定義されていないと仮定すると、「${aName:-golden}」は「golden」として解釈されます。
入れ子になった変数
変数のネストは完全にサポートされています。変数の名前、デフォルト値、および値定義の両方で、他の変数を参照できます。
変数のネストは完全にサポートされています。変数名、デフォルト値、および値の定義はすべて、他の変数を参照できます。