[B! Java][logging] decoy2004のブックマーク

Javaのロギングライブラリの歴史と現状をふんわり把握する（初学者向け） - Qiita

かつて、Log4jというロギングライブラリがありました。最強でした。1999年のお話です。ロギングの大切さとLog4jの素晴らしさが見直され、Java標準にjava.util.loggingというAPIが追加されました。2002年のお話です。 java.util.loggingはLog4jを参考に作られましたが、ところどころ使いづらかったため、「標準」という武器をもってしても、Log4jに置き換わることはできませんでした。そのため、Javaの世界には2つのロギングライブラリが残ってしまいました。 Maven1.0が2004年にリリースされ、人々はOSSライブラリを組み合わせてアプリケーションを作るようになりました。ところが、ロギングライブラリが2つあったため、Log4jを使っているライブラリと、java.util.loggingを使っているライブラリが混在してしまい、アプリケーション

decoy2004 2016/06/12

java
logging

リンク

Javaライブラリを配布する際のログ周りにおける配慮と実践 - Kengo's blog

2020-07-22更新: 以下の投稿で情報をアップデートしています。 https://blog.kengo-toda.jp/entry/2020/07/21/223136 いつも購読させていただいている id:teppeis さんのブックマークに以下のエントリが流れてきて、なるほどこいつはたしかに厄介だと思いました。 javaのロガーが多すぎて訳が解らないので整理してみました - 文系プログラマによるTIPSブログただSLF4Jが最も先進的かつ著名なインタフェースである以上、配布側としてはSLF4Jを使いつつ問題を解決したいところです。他のインタフェースを使ったりオレオレ実装を使ったりしてしまうと、それこそユーザの自由度を奪ってしまう形になります。実際、SLF4Jを配布パッケージに含めないという簡単な解決法がありますので、簡単に紹介します。悲劇を繰り返さないためにライブラリ開発者がす

decoy2004 2015/03/14

『配布パッケージにSLF4JのAPIが含まれていたり、配布パッケージがSLF4JのAPIにcompileスコープで依存していたりすると、ユーザがいちいちexclusionで依存を断ち切らなければなりません』

リンク

[Java]Java SE標準ロギングのプロパティ設定で複数のファイルにログを分けて出力する - torutkのブログ

プロパティファイルでロギング設定をする場合、デフォルトではFileHandlerクラスに対してロガーへの紐付け、ファイル名、ログレベル、ローテーションなどを定義するルールとなっています。そのため、プロパティファイルを使った設定方法では、実レベルでよく必要となるログの用途に応じてファイルを分けるという運用を定義することができません。プロパティファイルではなくプログラムでAPIを読んで設定する必要があります。ところが、これとは別のアプローチがありました。 http://stackoverflow.com/questions/3639694/java-util-logging-properties-how-to-log-to-two-different-files これによると、標準のjava.util.logging.FileHandlerとは別に、FileHandlerのサブクラスを作って

decoy2004 2014/08/20

リンク

Java Logging API vs Log4j

◎…優位 (だがオーバースペック気味)、○…十分に実用レベル △…使用に難あり、×…必須要件なら選択不可使う側にしてみれば必要な実装が一通り揃っておりパフォーマンス的にも有利な Log4j を選択したいところです。特に大規模なシステム開発では、チームごとに自分たちのドメインの設定ファイルを作成したり、設定ファイル上でパッケージごとの出力先を分けられる必要が出てきます。また運用要件で syslog などを使用する必要が出てくるかも知れません。しかし必要な要件をどちらも満たしているのであれば、実質的にこの選択は JAR の追加配備に問題があるかどうかで決まります。 Log4j 推奨 JAR の追加配備が容易な場合。具体的にはサーブレットや EJB などのサーバサイド開発。あるいはイントラネットで Java Web Start を使用したり、インストーラが整っているリッチクライアント。技

decoy2004 2014/07/05

リンク

他のロギングライブラリの呼び出しをLog4j2へ転送する＋α - CLOVER

Log4j2は、他のロギングライブラリの呼び出しを、Log4j2に転送するコンポーネントを提供しています。要は、他のロギングライブラリのふりをしてLog4j2へ流すコンポーネントがあるということですね。以下のパターンがあります。 Log4j 1.2 → Log4j2 Commons Logging（JCL） → Log4j2 SLF4J → Log4j2 Log4j2 → SLF4J 最後だけ、逆ですね。これが＋αの部分です。それぞれのMaven依存関係は、こちらに網羅されています。 Maven and Ivy Artifacts http://logging.apache.org/log4j/2.x/maven-artifacts.html では、それぞれ簡単に使っていってみます。なお、基本的にこれらのAPIを動作させるのに、本物のライブラリ（例えばLog4j 1.2のJARファイ

decoy2004 2014/06/29

リンク

Log4j2を試してみる - CLOVER🍀

Javaのロギングライブラリですが、 java.util.logging（JUL） Log4j Commons Logging（＋Log4j） SLF4J＋Logback と種々あり、最近ではSLF4J＋Logbackが主流な気がするのですが、自分の周りでは長らくLog4j、またはCommons Loggin越しにLog4jのパターンが多かったです。というか、今もですが。 Log4jの上に、自作のロギングライブラリを作ることになることも、多々…。まあ、そんな感じで昨今のJavaのロギング事情にだいぶ置いていかれているのですが、ここでちょっとLog4jの後継であるLog4j2を試してみたくなりまして。 Apache Log4j2 http://logging.apache.org/log4j/2.x/ なんでも、パフォーマンスがかなり良くて有名？らしいのですが。 The Logging O