TOC

SLF4Jの紹介

SLF4Jの概要

1. 概要

Java用のシンプルなログファサード（略称SLF4J）–さまざまなログフレームワークのfacadeとして機能します（例： java.util.logging, logback, Log4j）。 ロギングを実際の実装から独立させる汎用APIを提供します。

これにより、さまざまなロギングフレームワークを共存させることができます。 また、あるフレームワークから別のフレームワークに移行するのにも役立ちます。 最後に、標準化されたAPIとは別に、いくつかの「シンタックスシュガー」も提供します。

この記事では、SLF4JをLog4j2、Logback、Log4J2、およびJakarta Commons Loggingと統合するために必要な依存関係と構成について説明します。 この実装の詳細については、記事Introduction to Java Logging.を参照してください。

2. Log4j2のセットアップ

Log4j2でSLF4Jを使用するには、次のライブラリをpom.xmlに追加する必要があります。 


    org.apache.logging.log4j
    log4j-api
    2.7


    org.apache.logging.log4j
    log4j-core
    2.7


    org.apache.logging.log4j
    log4j-slf4j-impl
    2.7

最新バージョンはここにあります：log4j-api、log4j-core、log4j-slf4j-impl。

実際のロギング構成は、ネイティブLog4j 2構成に準拠しています。 Loggerインスタンスがどのように作成されるかを見てみましょう。 

public class SLF4JExample {

    private static Logger logger = LoggerFactory.getLogger(SLF4JExample.class);

    public static void main(String[] args) {
        logger.debug("Debug log message");
        logger.info("Info log message");
        logger.error("Error log message");
    }
}

LoggerとLoggerFactoryはorg.slf4jパッケージに属していることに注意してください。 説明された構成で実行されているプロジェクトの例は、利用可能なhereです。

3. ログバックの設定

LogbackでSLF4Jを使用するために、クラスパスにSLF4Jを追加する必要はありません。 ログバックはすでにSLF4Jを使用しています。 これはリファレンス実装と見なされます。 Logbackライブラリーのみを含める必要があります。 


    ch.qos.logback
    logback-classic
    1.1.7

最新バージョンはここにあります：logback-classic。

構成はログバック固有ですが、SLF4Jとシームレスに機能します。 適切な依存関係と構成が適切に設定されていれば、前のセクションの同じコードを使用してロギングを処理できます。

4.The Log4j Setup

前のセクションでは、特定のロギング実装の上にSLF4Jが「収まる」ユースケースを取り上げました。 このように使用すると、基盤となるフレームワークが完全に抽象化されます。

既存のロギングソリューションを置き換えることができない場合があります。 サードパーティの要件によります。 ただし、これは、プロジェクトが既に使用されているフレームワークに対してのみ「文章化」されることを意味しません。

SLF4Jは、既存のフレームワークへの呼び出しがリダイレクトされるブリッジとして構成できます。 Log4jのブリッジを作成するために必要な依存関係を追加しましょう。 


    org.slf4j
    log4j-over-slf4j
    1.7.21

依存関係が設定されていると（最新のlog4j-over-slf4jを確認してください）、Log4jへのすべての呼び出しはSLF4Jにリダイレクトされます。 既存のフレームワークのブリッジングについて詳しくは、official documentationを検討してください。

他のフレームワークと同様に、Log4jは基礎となる実装として機能できます。 必要な依存関係を追加しましょう： 


    org.slf4j
    slf4j-log4j12
    1.7.21


    log4j
    log4j
    1.2.17

slf4j-log4j12とlog4jの最新バージョンはここにあります。 説明された方法で構成された例示的なプロジェクトは、利用可能な％（ｔ２）である。

5. JCLブリッジのセットアップ

前のセクションでは、同じコードベースを使用して、異なる実装を使用したロギングをサポートする方法を示しました。 これはSLF4Jの主な約束と強みですが、JCL（Jakarta Commons LoggingまたはApache Commons Logging）の背後にある目標でもあります。

JCLは、その意図により、SLF4Jに類似したフレームワークです。 主な違いは、JCLは、クラスロードシステムを介して実行時に基礎となる実装を解決することです。 このアプローチは、カスタムクラスローダーが動作している場合に問題があると考えられています。

SLF4Jは、バインディングをコンパイル時に解決します。 シンプルでありながら十分に強力であると認識されています。

幸いなことに、ブリッジモードでは2つのフレームワークを連携させることができます。 


    org.slf4j
    jcl-over-slf4j
    1.7.21

最新の依存関係のバージョンはここにありますjcl-over-slf4j.

他の場合と同様に、同じコードベースで問題なく実行できます。 このセットアップを実行する完全なプロジェクトの例は、利用可能なhereです。

6.さらにSLF4J Goodness

SLF4Jは、ロギングをより効率的にし、コードを読みやすくするための追加機能を提供します。 たとえば、SLF4Jは、パラメーターを操作するための非常に便利なインターフェイスを提供します。 

String variable = "Hello John";
logger.debug("Printing variable value: {}", variable);

同じことを行うLog4jのコード例を次に示します。 

String variable = "Hello John";
logger.debug("Printing variable value: " + variable);

ご覧のとおり、Log4jは、debugレベルが有効かどうかに関係なく、Stringsを連結します。 高負荷のアプリケーションでは、これによりパフォーマンスの問題が発生する場合があります。 SLF4Jは、debugレベルが有効になっている場合にのみ、Stringsを連結します。 Log4Jで同じことを行うには、debugレベルが有効になっているかどうかを確認するifブロックを追加する必要があります。 

String variable = "Hello John";
if (logger.isDebugEnabled()) {
    logger.debug("Printing variable value: " + variable);
}

SLF4Jは、特定の実装で異なるロギングレベルを標準化しました。 ロギングフレームワークでは、アプリケーションをいつ終了するかを決定するべきではないという前提に基づいて、FATALのロギングレベルが低下しました（Log4jで導入されました）。

使用されるログレベルはERROR, WARN, INFO, DEBUG, TRACEです。 それらの使用について詳しくは、Introduction to Java Loggingの記事をご覧ください。

7. 結論

SLF4Jは、ロギングフレームワーク間のサイレントスイッチングを支援します。 シンプルでありながら柔軟性があり、読みやすさとパフォーマンスの改善が可能です。

いつものように、コードはover on GitHub.にあります。さらに、異なる記事専用の他の2つのプロジェクトを参照していますが、ログ構成について説明しているhereとhereが含まれています。

Related