少し前に、Javaでのロギングをより使いやすく、シンプルにし、同時に非常に柔軟な構成にするというアイデアが思いつきました。 このような要件は、かさばる
log4jなしで実行できる中小規模のプロジェクトでおそらく当てはまります。 文字通り1週間で、アイデアは同様に単純な名前
-logyを持つ単純なJavaライブラリに成長しました。
使用法:
import static logy.Logy.*; public class Test { public void test() { String s[] = {"a", "b"}; warn("Can't find", quote(upper("c")), "in", group(quote(upper(scalar(s))))); } }
結論:
29.06.2012 1:19:25 Test.test [WARN] :: Can't find "C" in ["A", "B"]
私にとっては、構文糖、
DSLのような API、および呼び出し時のロギングパラメータの動的な定義のおかげで、非常に読みやすくなっています(クラスの
public static final Logger logger = ...
を追加せずに読み取ります)。
タイトルについて
単語「logy」-英語から「ダム」と訳されています。 一方では、名前は「ログ」のちっぽけなものとして認識され、他方では、ライブラリの狭量性(良い意味で)とシンプルさを暗示しています。
機能/機能
- コンパイルされたJARファイルで17kbかかります
- 依存関係なし
- DSLのようなAPI:引用、グループ、上部、エクスポート、...
- ロギングパラメータの動的な定義(ロガーの明示的な初期化なし)
- ファイル/ stdout / stderrへのロギング
- 構成ファイルでのマスクサポート(「*」)
- 「グローバル」〜「メソッド」の範囲の構成
API
logy APIは、1つの行でプロジェクトにインポートできる
可変数のパラメーターを持つ静的メソッドのセットです。
import static logy.Logy.*;
優先度の高い順に5つのメッセージレベル:「デバッグ」、「罰金」、「情報」、「警告」、「エラー」は、同じメソッドで表されます。
例:
error("Files", quote("file1", "file2"), "not found!").
結論:
Files "file1" "file2" not found!
「export」メソッドを使用して、変換の結果を文字列にエクスポートします。
例:
String s = export("The", quote(upper("message")), "can't be delivered!"); System.out.println(s);
結論:
The "MESSAGE" can't be delivered!
引用符でパラメータを引用します。
例:
int arr[] = {1, 2, 3, 4}; info("Quotted values:", quote(scalar(arr), "a", "b"));
結論:
Quotted values: "1" "2" "3" "4" "a" "b"
「グループ」メソッドを使用して結果をグループ化します。
String s[]= {"a", "b", "c"}; info("Grouped values:", group(scalar(s), 1, "d"));
結論:
Grouped values: [a, b, c, 1, d]
「upper」および「lower」メソッドを使用してパラメーターのレジスターを変更します。
例:
String s[]= {"a", "b", "c"}; info("Uppered values:", upper(scalar(s))); info("Lowered values:", lower("A", "B", "C"));
結論:
Uppered values: ABC
Lowered values: abc
「スカラー」および「配列」メソッドを使用したパラメーターの使用例の明確化。
例:
int arr[] = {1, 2, 3, 4}; info("Quotted array:", quote(array(arr))); info("Quotted values:", quote(scalar(arr)));
結論:
Quotted array: "[1, 2, 3, 4]"
Quotted values: "1" "2" "3" "4"
構成
構成ファイルは、次の定義をサポートしています。
- 「#」で始まるコメント
- 「VARIABLE @ SCOPE = VALUE」という形式のトリプル
たとえば、グローバルメッセージフォーマットを設定するためのトリプルは次のようになります。
format@=%date% %time %class% [%level%] %%%
以下のコンテキスト変数が利用可能な場合:
- %scope%-ロガーが呼び出されるメソッドへのフルパス
- %class%-ロガーが呼び出されるメソッドのクラスへのフルパス
- %method%-ロガーが呼び出されるメソッドの名前
- %date%-ロガーが呼び出された時点の日付、現在のロケールの形式
- %time%-ロガーが呼び出された時刻、現在のロケールの形式
- %level%-ロガーメッセージレベル
- %%%-ロガーメッセージ
変数のスコープを設定する際の主な機能は、パスでのマスク「*」の使用です。
簡単な例を考えてみましょう。 テストクラスからすべてのメッセージをファイルに記録し、他のクラスからコンソールにエラーのみを記録するとします。 これを行うには、プロジェクトのルートに「properties.logy」というファイルを作成し、次の内容を含めます。
計画
ロジーは、常に狭いタスクを解決する最小限のツールのままにしておきたいです。 したがって、たとえば、データベース、ネットワークなどのロギングサポートなど、新しい機能が大規模にプロジェクトに組み込まれることはありません。 プロジェクトの対象読者は、このような機会が必要とされない可能性が最も高い中小規模のプロジェクトです。
現在、実際に不足している唯一のことは、a)1つの使用領域(現在、残念ながら、1つのみ)に対する複数のロガーのサポートです。 b)マルチスレッド環境での正しい操作(実際にはチェックしませんでしたが、特にファイルにログを記録する場合は問題があると思われます)。
バージョン
0.2.0
では、近い将来これらの変更を行う予定
0.2.0
。
PS
もちろん、ライブラリのすべての機能については説明しませんでした。 より詳細なドキュメント(執筆中)は、
GitHubプロジェクトページにあります 。
フィードバック、フォーク、プールリクエスト、バグレポートに非常に喜んでいます。
アナログについては。 私は結局この質問を無駄にしたわけではありません。 正直なところ、私は実際に類似の機能と機能を持つライブラリを見つけようとしませんでした。 おそらく、完全に自分で何かを書きたかったのか、頭の中のすべての新しいアイデアの前で「はい、すでにこれを思いついたので、食べに行きます」といった言い訳を探すのにうんざりしていて、実装を渇望しています。 さらに、本当に新しいものを思いつくことはほとんど不可能であり、他の人よりもうまくやることが可能であることが知られています。