« Welding GWT-RPC with CDI @ConversationScoped | トップページ | Eclipseのちょっと賢いスニペットプラグイン Code Recommenders »

2015/10/12

みんな本当にloggerをinjectionしたいなんて考えてるの?

CDIについてwebで検索していると、しばしばloggerをinjectするのが便利だと説明されているサイトに当たります。
以下に検索でヒットしたサイトの例と、そこに書かれているロガーをインジェクションすることのメリットあるいは動機を引用します。

ほとんどのサイトで、タイピングの手間が省けることがメリットであると書かれていました。
私からするとこの程度の手間の省略は、コンパイル時に解決できることを実行時まで遅延させる理由付けとしては弱すぎるように感じるのです。
世間一般的には十分受け入れられる動機なのでしょうか?
(例外からクラス名を取得するような手法を紹介されている方もいらっしゃいますが、これも同様に行うべきではないと私は考えています。)


単にタイプの手間を減らしたいだけであれば、私はIDEのスニペット機能を推奨します(次のエントリでEclipseの便利プラグインを紹介します。他のIDEでも似たような機能が有るでしょう)。
(ロギングのためだけに導入するのは首肯しかねますが、既に別の用途で導入済みであるなら)lombokの@Logアノテーションを用いてもコンパイル時に解決します。


JUL特有の問題の対策として、以下のように説明されている方がいらっしゃいました。
確かにコンパイル時には解決できないのでこのような理由でCDIを用いることには一理あると思いますが、一般的にはloggerはアプリケーション固有のクラスローダでロードする、すなわち設定は個別に行えるので一般的には当てはまらないと思います。
(そして更に言うと、一般的にはJULを使わない…ですよね?)


Java EE環境でjava.util.loggingとうまく付き合う方法 | Nishigaya's Tech Blog

複数のJava EEアプリが同一サーバ上に同居することを想定した場合、もう一つ注意すべき点があります。それは、「Loggerオブジェクトは、名前毎に生成されるJVMレベルでのシングルトン・オブジェクトである」ため、同居する複数のアプリが同じ名前のロガーを取得してしまうと、互いにロガーの設定に影響しあってしまう点です。先ほど、ロガー名にはパッケージ名を使用するのが望ましいということを述べましたが、異なるアプリでも共通のフレームワークやビジネスオブジェクト、バリューオブジェクトなどは同じクラス群をライブラリとして共通に使用するのが一般的で、そうするとどうしてもこれらのクラスについては、アプリが異なっても同じロガー名を使用してしまいます。せっかく、アプリ毎に異なるログファイルを設定しても、一方のアプリのログが他方のアプリのログに混じってしまうようなことが発生します。この問題を避けるためには、同じクラスを使ってもアプリ毎に必ず異なるロガー名が使われるようにしなければなりません。Java EE 6の環境であれば、アプリ名はJNDIリソースを通じてランタイムに取得することができますので、以下のようにして、ロガー名が”<アプリ名>.<パッケージ名>”のようにすることができます。

« Welding GWT-RPC with CDI @ConversationScoped | トップページ | Eclipseのちょっと賢いスニペットプラグイン Code Recommenders »

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/18902/62461678

この記事へのトラックバック一覧です: みんな本当にloggerをinjectionしたいなんて考えてるの?:

« Welding GWT-RPC with CDI @ConversationScoped | トップページ | Eclipseのちょっと賢いスニペットプラグイン Code Recommenders »

other sites

  • follow us in feedly
  • github
  • stackoverflow

ソフトウェアエンジニアとして影響を受けた書籍

  • Christain Bauer: HIBERNATE イン アクション

    Christain Bauer: HIBERNATE イン アクション
    理論と実践が双方とも素晴らしい製品であるHibernate。本書はそのプロダクトを書名に冠していますが、Hibernateを使うつもりがなく、ORマッピングの解説書として読むにしても十分な良書です。Second EditionとしてJava Persistence With Hibernateという書籍も出版されていますが、残念ながら現在のところ 和訳はされていません。-インアクションは2.xの、Java Persistence-は3.1の頃のものなので、最新版とはちょっと違うところもあることに注意。 (★★★★★)

  • アンドリュー・S・タネンバウム: 分散システム 原理とパラダイム 第2版

    アンドリュー・S・タネンバウム: 分散システム 原理とパラダイム 第2版
    クライアント/サーバシステムを構築する上で必要となる知識が総論されてます。Web技術者も、フレームワーク部分を開発するのであれば必読。 (★★★★★)

  • Joel Spolsky∥著: ジョエル・オン・ソフトウェア

    Joel Spolsky∥著: ジョエル・オン・ソフトウェア
    前述の書籍「ソフトウエア開発プロフェッショナル」をより砕いたもの、という感じでしょうか。 前書きではプログラマでなくSE向けの本のように書かれているが、プログラマが読んでも面白い本であると思われます。 SEになった新人(あるいはそういう会社に入る/入りたての人)にとっては、これからどういったことが仕事を遂行していく上で起こりえるのか、どのように考えて行なっていけばいいのか決定する助けになると思います。 元は″Joel on Software″というブログの記事で、web上でも一部日本語で読めます。 http://japanese.joelonsoftware.com/ (★★★)

  • ドナルド・C・ゴース,ジェラルド・M・ワインバーグ: ライト、ついてますか

    ドナルド・C・ゴース,ジェラルド・M・ワインバーグ: ライト、ついてますか
    問題解決(一昔前のの流行語で言うところの『ソリューション』)能力は、システムエンジニアのスキルとして備えるべきもののうちのひとつです。しかし、これは難しい。学校で出されるテストと違い、唯一の、(問題提出者が想定している)解を求めるだけが「問題解決」では無いからです。そもそも、何が問題なのか、それは本当に問題なのか、それは本当に解決すべき問題なのか、その問題解決方法は正しいのか、などを解決しなければ、「その解は正しいのか」に辿りつくことができません。この本の最も良いところのひとつは、本があまり厚くないこと。すぐに読めるし、何回も読み返す気になるでしょう。 (★★★★★)

  • スティーブ・マコネル: ソフトウエア開発プロフェッショナル

    スティーブ・マコネル: ソフトウエア開発プロフェッショナル
    コードコンプリートで有名なスティーブマコネルの著書。新人SEに読んで欲しい。個人として業界の中でどうあるべきか、組織としてどうあるべきか、SEのプロ意識とは?SEの心構え概論、といったところでしょうか。また、業界における資格の重要性についても説かれています。この業界では資格が特に軽んじられる傾向がありますが、この傾向はどんな弊害をもたらすのか、将来的にこの業界は資格に対してどのような姿勢で臨んでいくべきなのか。日経BP社では(他の出版社もだが)最近、似たような類いのあまり面白くない書籍が乱出版されていますが、この本は別格だと思うので安心して購入して欲しいと思います。 (★★★★★)

無料ブログはココログ