SLF4Jロガー工場

Question

私はSLF4Jは、反射を経てorg.slf4j.impl.StaticLoggerBinderをロードするだろうと思ったが、org.slf4j.LoggerFactoryのコードを見て、それはそうではありません。

StaticLoggerBinder.getSingleton().getLoggerFactory(); 

それは彼らがSLF4J-api.jarのをパッケージ化するとき、彼らが持っていたことを示唆しているかもしれませんどちらかとして循環依存につながるSLF4J-simple.jarしかし、クラスパスに（またはSLF4J-nop.jar）ILoggerFactory上記のインターフェイスメソッドの戻りSLF4J-api.jarのに定義されています。

だから、私は彼らがSLF4J-api.jarのをパッケージ化するとき、彼らはコンパイルが、その後のjarから.classファイルを削除することになるStaicLoggerBinder（および他の類似のクラス）のスタブ実装を持っていたと思います。少し不道徳なようですね。

ビルドツールのどのような種類の一つは、このような結果を達成するために使うのでしょうか？私はMavenを使用していた場合に具体的に、どのように私は、コンパイル時に生成するクラスは、アーティファクトから除外されているようにjarファイルをビルドするのですか？彼らはあまりにも除去しなければならない、あまりにも生産され、匿名や他のネストされた/インナークラスがあるかもしれませんか？

Answer 1

pom.xmlとslf4j-apiのソースを参照してください。

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-antrun-plugin</artifactId> 
    <executions> 
     <execution> 
     <phase>process-classes</phase> 
     <goals> 
     <goal>run</goal> 
     </goals> 
     </execution> 
    </executions> 
    <configuration> 
     <tasks> 
     <echo>Removing slf4j-api's dummy StaticLoggerBinder and StaticMarkerBinder</echo> 
     <delete dir="target/classes/org/slf4j/impl"/> 
     </tasks> 
    </configuration> 
    </plugin> 

だから、私は彼らがSLF4J-api.jarのをパッケージ化するとき、彼らはコンパイルが、その後のjarから.classファイルを削除しますStaicLoggerBinder（および他の類似のクラス）のスタブ実装を持っていたと思います。

これは正しく、static bindingを実装する必要があります。

Answer 2

「だから、私は、彼らはSLF4J-api.jarのをパッケージ化するときだと思う、彼らはコンパイルが、その後のjarから.classファイルを削除しますStaicLoggerBinder（および他の類似のクラス）のスタブ実装を持っていた。サウンズビットunkosher、それじゃない？ "それはイエス行うの方法です

。私はそれが不公平だとは言いません - それは、単純な方法で複数の実装をサポートするために必要な "悪"です。 SLF4J StaticLoggerBinder