先日InfoQでお伝えしたように，Apache Software Foundationは，人気ロギングフレームワークのLog4jバージョン１のサポート終了(EOL/End of Life)を発表し，ユーザに対してバージョン２への移行を推奨した。
InfoQでは以下のApache Logging Services Teamメンバとコンタクトを取り，Log4jの新バージョン移行に関する詳細と，今後の予定について聞いた – Apache Logging PMCでLog4j 2イニシアティブのRalph Goers氏，Apache Logging PMCメンバのRemko Popma氏とGary Gregory氏，Apache Logging責任者のChristian Grobmeier氏。
InfoQ: Log4j2は公開されてちょうど1年になりますが，Maven Centralの統計によれば，バージョン１の方がバージョン２より多く利用されているようです。今回のEOLはユーザにとって，新バージョン移行の動機になるでしょうか？
Remko: 少なくとも，log4j 2の存在がもっと意識されるようにはなると思っています。特に問題がなければ，何かを変える気にはあまりならないというのは，十分に理解できますが，このEOLを機会として，少なくとも新しいプロジェクトではLog4j 2を使って欲しいですね。
Christian: EOLは単なるマークですが，今後Log4j 1リリースに対して多くの時間が投資されることはない，ということが誰の目にも明らかになったはずです。バージョン１リリースは非常に複雑ですし，今後新たなリリースが行われないので，セキュリティ上の問題を引き起こす可能性があります。 実際にはLog4j 1にもバグトラッカが用意されていて，誰でもまだ問題を報告できるようにはなっていますが，パッチが提供されない限り，それらをフィックスする予定はありません。セキュリティ上の理由だけでも，アップグレードについて検討するべきだと思います。
InfoQ: Log4jが新バージョンに書き直された大きな理由は，バージョン１にあった数多くのアーキテクチャ的な問題を解決するためだと思うのですが，単純なログ機能が必要なユーザもたくさんいると思います。新しい機能を必要としない，そういったユーザに対して，バージョン２への移行をどのように説得しますか？
Remko: “単純なログ機能が必要”というのは，“将来的なログ機能の必要性の分析や，選択肢を比較する時間がない”という意味であることも少なくありません。それはよく分かります。そういったユーザには，Log4j 2が最適だと思います。簡単に利用できて，動作も非常に高速です。将来的な機能拡張に対しても，機能的な深さと柔軟性を十分に備えています。
Ralph: 私たちはユーザに対してLog4j 2にアップグレードするように勧めていますが，彼らが希望する限り，Log4j 1に固執するのはもちろん自由です。但し，Log4j 1で見つかった問題を報告することは今後も可能ですが，自分自身でパッチを用意するか，あるいは誰か他の人がそうしてくれない限り，問題が解決されることはありません。その点は理解しておく必要があります。
Gary: 私たち(開発者)には自明なことですが，すべての人たち(ユーザ)にはそうでない点があります。それは私たちがみなボランティアであること，つまり，時間やリソースが限られているということです。ですから，限られたリソースを最も効率的に使う方法は何なのかを決める必要があります。Log4j 1の変更はとても難しいので，同じ労力をバージョン２に集中した方が，より多くの価値を得ることができるのです。
もうひとつは，EOLは言葉の上に過ぎないということです。誰か名乗り出てくれれば，リリースもあり得ます。ただし問題の中には，新しいアーキテクチャとバージョンでなければ，簡単には対処できないものもあります。
InfoQ: Log4jバージョン１の利用を止めることになれば，単にバージョン２にアップグレードするのではなく，別のロギングフレームワークへの移行を検討する開発者も多いと思うのですが，そのような心配はありませんか？
Remko: Log4j 2は他の選択肢に対して，十分な競争力があると自信を持っています。それを証明するために，特に注目してほしい特徴が，Log4j 2にはいくつかあります。
- コミュニティのサポート: Log4j 2には活発なコミュニティがあって，質問への回答や機能の追加，バグ修正などが行われています。
- パフォーマンスへの影響が極めて低い: Asynchronous Loggerによって，ログを完全にオフにした場合とほとんど同じレベルのパフォーマンスを提供します。
- 安定性と信頼性: コンフィギュレーション修正時，自動的に再読み込みを実行します。再設定の実行中でもログイベントを失うことはありません。
- カスタムログイベントやフィルタリング(コンテキストデータ，マーカ，正規表現，その他のログイベント構成要素に基づく)，ルックアップといった，豊富な機能を備えています。
- プラグインアーキテクチャ: カスタムコンポーネントを開発することで容易に拡張可能です。
- APIサポート: 直接使用する以外に，SLF4J，Commons Logging，Log4j 1，java.util.logging経由で使用することも可能です。
- 2.4リリースでJava 8のラムダ式をサポートする予定です。
InfoQ: Log4jバージョン1のEOLのタイミングは適切だったと思いますか？もしも変更するとしたら，もっと以前か，後か，あるいは今と同じですか？
Remko: 正しかったと思います。Log4j 2はすでに19回のリリースを重ねてきましたし，直近の６回はGA(General Availability)としてマークされています。GAリリースになって1年以上になるということが，十分に安定していることの証明になります。このことから，Log4j 2はLog4j 1の代替として安全であると考え，前バージョンの終了を宣言するにはよいタイミングだと思ったのです。
Ralph: 今回のEOLに関する発表は，Log4j 1のバグ修正を誰も行っていない，今後も行う予定がないという事実を報告したに過ぎません。その意味では，バージョン１はもうずっと前にEOLに達していたとも言えます。私たちに必要だったのは，Log4j 1を公式にリタイアさせる前に，Log4j 2を安定した，信頼できる代替品にすることだったのです。
InfoQ: ログの分野で 今後，大きな課題となりそうなものは何だと思われますか？Log4jに関してはどうでしょう？
Remko: 個人的には，Log4j 2のパフォーマンスを，特に同期ロギングのシナリオで改善していきたいと思っています。この領域では，まだ改善の余地がたくさんあると思うのです。大局的な課題としては，おそらくログ管理でしょう。コレクション，中央集約，長期保持，ログの解析や検索，報告といった分野です。このような問題に取り組んでいる製品もありますし，もし標準化が行われれば，Log4jもそのような作業を支援することができるとおもいます。
Apache Software Foundationでは，バージョン１からバージョン２へのアップグレードを望むユーザ向けのマイグレーションガイドや，バージョン２の採用を推奨するLog4j 2の機能概要などを用意している。