Logy — логгер с человеческим лицом

[@VoVanJinn]

А ничего, да, уютненько! Пожалуй возьму побаловаться.
Спасибо!

[@spiff]

Пожалуйста! :) Отправляйте баг-репорты, уверен я протестировал не все.

[@BlackSwan]

А с андроидовским LogCat оно работаеть умеет? Если нет — реквестирую сборку библиотеки для андроид-программистов.

[@spiff]

Нет нет, это только для Java SE/EE. На счет Андроида надо подумать. Я никогда не писал под него. Можете форкнуть и написать врапперы :)

[@GreyCat]

Там, насколько я вижу, все используемые вами классы вполне себе будут. Единственное — вместо вывода в файл или stream надо будет докрутить вариант вывода в logcat — можно по аналогии с «stream:err», например, сделать «logcat:something».

[@spiff]

Дада. Можно будет просто создать новый класс расширяющий logy.logger.Logger

[@GreyCat]

Эм, я, конечно, все понимаю, но, по-моему, import static logy.Logy.* как-то совсем жестоко замусоривает symbol space. Получить такие слова, как:

• join
• group
• fetch
• quote
• export

и огрести очень возможные пересечения с локальными символами — по-моему — не самая хорошая идея.

Ну и да, как-то совсем странно видеть публикацию библиотеки совсем без javadoc.

[@spiff]

javadoc пишется и будет в ближайшее время на ровне с документацией.

По поводу слов. Я думал над этим, но соблазн использовать красивые и понятные названия методов был настолько большим, что я не смог устоять :) Честно говоря не могу сказать на сколько часто я использовал данные названия для переменных/методов. «quote» точно ни разу не писал.

[@AlexanderYastrebov]

Автор, просто интересно, вы слышали про slf4j? Если да, то не очень понятны предпосылки создания вашей библиотеки. Какие у нее преимущества?

[@spiff]

Слышал. Последний абзац поста как раз отвечает на вас вопрос.

[@AlexanderYastrebov]

В вашем подходе с DSL (который дает весьма сомнительные плюшки, кстати) есть один большой минус: куча вызовов instanceof и созданий массивов даже в тех случаях, когда сообщение не будет выводиться в лог

[@spiff]

Нене. Ну про плюшки это вы зря. Каждому свое, мне например нравится писать так, как было показано в примерах. Насчет масивов и instanceof тут да — ничего не поделаешь, хотя можно кеширование какое-нибудь прикрутить. Ну это если тормозить будет. Пока ни кто не жаловался — значит летает все :)

[@AlexanderYastrebov]

Пока никто и не пользовался, поэтому жалоб и нет :)
Насчет массивов можно решить по другому:

logger.debug("Can't find {quote,upper} in {quote,upper}", "c", s);

[@spiff]

Хм. nice try :) Такой подход где-то используется? Или только что придумали?

[@AlexanderYastrebov]

Ну это импровизация на тему расширения возможностей синтаксиса slf4j :)

[@AlexanderYastrebov]

У вас плюшек то и нет никаких, только изменение регистра и закавычивание.

[@spiff]

Ну как это и есть плюшки.

[@alexandro]

я просто оставлю эту ссылку:
тыц
чтобы было понятно, почему в slf4j сделано так, как сделано.

[@spiff]

Ответил вот тут habrahabr.ru/post/146762/#comment_4942054

[@Timmmm]

Можно по подробнее о «динамическое определение параметров логированя (без явной инициализации логгера)». Есть подозрения что будут проблемы с производительностью.

[@spiff]

Дада. Предыдущий комментарий как раз об этом.

Я знаю, что получать стек трейсы удовольствие не из дешевых, но я сознательно сделал именно так. Целевой функцией у меня было — удобство использования. К тому-же преждевременная оптимизация блаблабла… Если действительно будут с этим проблемы, я обещаю подумать над другим способом получения параметров.

[@Timmmm]

Странно вы рассуждаете. Т.е. вы сначала предоставляете продукт а уже потом думаете о его производительности?
Удобство использования должно включать в себя оптимальную работу. Допустим я начал использовать вашу библиотеку а потом понимаю что он ужасно тупит при использовании. Что мне предложите делать тогда?

[@spiff]

Эм… зафайлить баг и привести цифорки о том на сколько оно тормозит.

[@Timmmm]

Этим разве не вы должны заниматься перед представлением вашей библиотеки? Таким образом тестировать ваш продукт будут другие разработчики?

[@spiff]

Я проводил функциональное тестирование. Performance тестов у меня нет. Я и не планировал их делать. Я не хотел сделать «быстро», я хотел «просто сделать». А потом, если возникнут проблемы у меня или у кого-то еще уже можно было бы заняться оптимизацией. Кажется так делают большинство людей.

[@Timmmm]

Если я правильно понял использовать эту библиотеку я должен на собственный страх и риск? «большинство людей» какое большинство? Логирование приложения одна из самых сложных задач в плане производительности и оптимизации, а вы даже не планировали performance тестов. Так «большинство хороших разработчиков» не делают.

[@spiff]

зануда

[@Timmmm]

Есть немного )

[@xonix]

Одна из основных проблем в системах логирования это скорость. Необходимо, чтобы логирование как можно меньше замедляло программу.
У Вас информация о классе и методе берется программно из стека вызовов, что обычно очень неоптимально, и всякие библиотеки типа log4j не рекомендуют вообще пользоваться такой возможностью в критичных к скорости программах.
Ну и по мелочи. Ваши вспомогательные функции принимаютс Object… а значит на каждый вызов оборачивают свои аргументы в массив, что тоже не прибавляет скорости.

[@xonix]

github.com/vkostyukov/logy/blob/master/src/main/java/logy/logger/FileLogger.java#L33

Открывать и закрывать файл на каждую запись в него? Не думаю, что это хорошая идея…

[@spiff]

Дада. Сначала был постоянный дескриптор, я просто решил упростить себе жизнь. Когда будут допиливать поддержку многопоточной среды, обязательно взгляну на это.

[@OnoIt]

Нормальная. Когда пользователи захотят 1 лог-файл для 4 серверов, придется добавлять дополнительно блокировку при открытии файла.

[@Ents]

group(quote(upper(scalar(s)))) — не могу согласиться что это очень читаемо ))))

[@spiff]

Возможно пример не очень удачный, можно было просто написать «s» — как массив.

[@voronaam]

Была где-то статья про историю логгеров в Java. Если кратко, каждый хотел сделать лучше и потому получилось много библиотек.

У нас тоже есть библиотека для более дружелюбного к программисту логгирования. Но, в отличие от вам, мы не стали переписывать весь логгер, вместо этого написали один класс с удобными функциями (в т.ч. и варианты с varargs), который затем вызывает ванильные методы log4j.

Советую и вам подумать в этом направлении…

[@xonix]

>Была где-то статья про историю логгеров в Java.

habrahabr.ru/post/113145/

[@skywatcher]

Конфигурировать как? Очень похоже на наколенную студенческую поделку с изобретением велосипеда. Если кому и надо будет такое, то это делается за 2 минуты путем враппинга slf4j/log4j/logback или что у вас там используется

[@spiff]

Вы пост читали вообще?

[@skywatcher]

Промахнулся с ответом

[@skywatcher]

Да уж наверное. И даже не поленилсчя посмотреть код на гитхабе, который оставляет желать лучшего

[@relgames]

log4j? прошлый век, все давно используют slf4j + logback

String s[] = {"a", "b"};
log.warn("Can't find '{}' in {}", "c", s);

выведет

22:28:19.443 [main] WARN  Test1 - Can't find 'c' in [a, b]

Приводить к UPPER CASE или еще как-то менять исходные данные противоречит самой сути логгирования, ведь логи ведутся не для красоты, а чтобы потом было проще понять, в чем проблема. А вдруг проблема именно в регистре? А в логах все строки будут в одном и том же регистре.