Logy - a logger with a human face

Some time ago I came up with the idea to make logging in Java more friendly, simple and at the same time quite flexible in setting up. Such requirements are probably true in a medium and small project, where you can do without the cumbersome log4j . Just over a week, the idea grew into a simple Java library with a no less simple name - logy .

Using:

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))))); } } 

Conclusion:
29.06.2012 1:19:25 Test.test [WARN] :: Can't find "C" in ["A", "B"]

As for me, it looks very readable, thanks to the syntactic sugar, the DSL-like API and the dynamic definition of the logging parameters at the time of the call (read without additional public static final Logger logger = ... fields in the class).

About the name

The word “logy” means “stupid” in English. On the one hand, the name is perceived as a diminutive from “log”, on the other - it hints at the narrowness (in a good way) and the simplicity of the library.

Features / Features

• takes 17 kb in compiled jar file
• no addictions
• DSL-like API: quote, group, upper, export, ...
• dynamic logging parameters definition (without explicit logger initialization)
• logging to the / stdout / stderr file
• mask support (“*”) in configuration files
• configuration in the range “globally” ... “method”

API

The logy API is a set of static methods with a variable number of parameters that can be imported into a project in one line:
')

 import static logy.Logy.*; 

5 levels of messages, in order of priority: “debug”, “fine”, “info”, “warn”, “error”, are represented by methods of the same name.

Example:

 error("Files", quote("file1", "file2"), "not found!"). 

Conclusion:
Files "file1" "file2" not found!

Exporting transformation results to a string using the “export” method.

Example:

 String s = export("The", quote(upper("message")), "can't be delivered!"); System.out.println(s); 

Conclusion:
The "MESSAGE" can't be delivered!

Wrapping parameters in quotes with the “quote” method.

Example:

 int arr[] = {1, 2, 3, 4}; info("Quotted values:", quote(scalar(arr), "a", "b")); 

Conclusion:
Quotted values: "1" "2" "3" "4" "a" "b"

Grouping results using the “group” method.

 String s[]= {"a", "b", "c"}; info("Grouped values:", group(scalar(s), 1, "d")); 

Conclusion:
Grouped values: [a, b, c, 1, d]

Change the register of parameters by the methods “upper” and “lower”.

Example:

 String s[]= {"a", "b", "c"}; info("Uppered values:", upper(scalar(s))); info("Lowered values:", lower("A", "B", "C")); 

Conclusion:
Uppered values: ABC
Lowered values: abc

Refinement of the option of using the parameter using the “scalar” and “array” methods.

Example:

 int arr[] = {1, 2, 3, 4}; info("Quotted array:", quote(array(arr))); info("Quotted values:", quote(scalar(arr))); 

Conclusion:
Quotted array: "[1, 2, 3, 4]"
Quotted values: "1" "2" "3" "4"

Configuration

Configuration files support the following definitions:

• comments starting with “#”
• triples of the form “VARIABLE @ SCOPE = VALUE”

For example, a triplet for configuring a global message format might look like this:

 format@=%date% %time %class% [%level%] %%% 

Where the following context variables are available:

• % scope% - full path to the method from which the logger is called
• % class% - full path to the class from which the logger method is called
• % method% - the name of the method from which the logger is called
• % date% - the date when the logger was called, in the format of the current locale
• % time% - time when the logger was called, in the format of the current locale
• % level% - logger message level
• %%% - logger message

The main feature when defining the variable usage area is the use of the “*” mask in the path.

Consider a simple example. Suppose you want to log all messages to a file from test classes and to log only errors from the other classes. To do this, create the file “properties.logy” in the project root, with the following content:

 #   level@=error logger@=stream:err #     “Test”     “test” level@*Test.test*=debug logger@*Test.test*=file:test.log 

Plans

I want logy to always remain a minimalistic tool that solves a narrow set of problems. Therefore, new features will probably not be merged into the project on a large scale, for example: logging support in the database, network, etc. The target audience of the project is small and medium projects, where such opportunities are most likely not needed.

The only thing that really lacks logy now is a) support for several loggers for one area of ​​use (now, unfortunately, only one); b) correct operation in a multithreaded environment (in truth, did not check, but I suspect that there will be problems, especially when logging to a file).

I plan to make these changes in the near future for version 0.2.0 .

PS

Of course, I did not tell about all the possibilities of the library. More detailed documentation (in the process of writing) can be found on the project's GitHub page .

I would be extremely happy with feedback, forks, pull requests and bug reports.

As for analogues. I knowingly left this question for last. Honestly, I didn’t really try to find a similar library and features. Probably because I wanted to write something completely of my own, or, I just got tired of looking for excuses like “yes, they have come up with this, I'll go and eat” before each new idea in my head, hungry for implementation. In addition, it is known that it is almost impossible to come up with something really new, it is possible to do it better than others.