Т.е. хотите - делайте 1 файл на поток, хотите отдельные файлы по уровням, Бобина всё это отлично поддерживает.

Никаких умозрительных ограничений и незадокументированных архитектурных проблем нет.

Пока я отвечу более детально, прошу всех скачать Бобину (через Maven, Gradle, jar - как удобно) и просто начать ей пользоваться.

Настроить по своим предпочтениям. И наслаждаться свободой от ига logback и прочих log4j.

Релиз 2.0.5 - он с учётом фидбека из этой темы.

maytondakeirasПока я отвечу более детально, прошу всех скачать Бобину (через Maven, Gradle, jar - как удобно) и просто начать ей пользоваться.

Настроить по своим предпочтениям. И наслаждаться свободой от ига logback и прочих log4j.
А ты хитрец. Хочешь бесплатную бригаду тестировщиков?

Ты с Панфиловым расчитался?
конечно! Ща как затестирую за ваш счет да как раскручусь, донат польётся рекой.

Кстати, правительсто оплачивает мне 10 опер сорс проектов, но я выкладываю только 5, остальные сам использую.

Как с тем армянином (который к сожалению умер) и бесплатным хлебом.

Basil A. SidorovdakeirasПросто с точки зрения здравого смысла, если у вас есть 500 потоков - писать лог в единый файл - это бред, наркомания укоренившаяся с годами.Нет задачи "писать лог в единый файл" и наркомания тут совершенно не в тему.
Если анализ проблемы требует анализ данных от пятисот потоков - так тому и быть.
И вот в этом случае собирать и синхронизировать данные из пятисот логов - проще сразу убиться, предварительно застрелив автора этой гениальной задумки.

Логгер «Бобина» позволяет удобно настраивать отображения вывода данных логирования в разных проекциях, в зависимости от необходимости:

- По потокам
- По уровню сообщения (error, debug, etc)
- По классам
- По MDC - например отслеживать работу по конкретному пользователю или по конкретному transaction id

Эти критерии можно группировать и комбинировать как угодно, например по группам потоков, пакетам классов - ограничений нет никаких.

1 сообщение может выводится во множество файлов одновременно.

Всё ещё хочется застрелить за такую идею? Плохая идея?

По остальным комментариям - отвечу с работы, заранее большое спасибо за тесты и фидбек.

LelouchdakeirasВсё ещё хочется застрелить за такую идею? Плохая идея?


За идею вас тут никто не расстреливают, просто никто кроме вас не видит преимуществ в этой идеи.
А вот реализация идеи хромает.

Человек выше написал:

авторзастрелив автора этой гениальной задумки

Мне лично хочется самому застрелиться от конфигов logback и log4jX.

Сейчас начну смотреть тесты и комменты.

Lelouch,

Огромное спасибо, что потратили время и сделали тесты.
Сейчас буду смотреть.

Респект.

maytondakeirasпропущено...


Человек выше написал:

пропущено...


Мне лично хочется самому застрелиться от конфигов logback и log4jX.

Сейчас начну смотреть тесты и комменты.
Ты ставишь нас в глупое положение. Ведь мы не видим те ужасные конфиги на которые
ты смотришь сейчас. Сделай милость. Приведи конфиг для одинаковой конфигурации для Робин-Катушка-Толтсяк
и Лог4Джей и Логбэк.

Вот несколько моментов описано:
https://github.com/INFINITE-TECHNOLOGY/BOBBIN/wiki/1---Introduction#problems

Это если чуть конкретнее.

Но в общем случае конфиги Бобины просто невоспроизводимы в других логгерах из-за функциональных ограничений SiftingAppender - либо огромные по размеру (отдельные блоки НА КАЖДЫЙ КЛАСС либо на весь пакет целиком)

Lelouch,

Посмотрел 1й тест: TestIOExceptionOnLog

Сделал PR: https://github.com/oleg-zinovev/bobbin-test-suite/pull/1

Бобина есть в JCenter, не обязательно ещё её собвстенный репозиторий подключать, это описано в инструкции:
https://github.com/INFINITE-TECHNOLOGY/BOBBIN/wiki/3---Usage#add-maven-dependency

Так же тест не воспроизводился под виндой из-за UAC Virtualization. Я чуть подправил.

Теперь касательно сути самого теста: это осмысленное поведение.
Я считаю, что выполнение не должно продолжаться при отказе системы логирования.

Принцип такой: чем раньше упадёт - тем лучше. А шанс того что упадёт само приложение чуть позже, если упал логгер - есть.

Это очередная "гениальная" фича в Logback - супрессить ошибки в логгере.

maytondakeiras, ты пишешь

Existing logging solutions provide only partial support for scripting in configuration.
Поясни эту фразу. Что значит scripting in configuration? Где partial? И где может быть full?

В Бобине full support скриптинга в конфиге, все поля это скрипты:
- levels
- classes
- fileName
- format
и пр.

Partial из документации к Бобине:
Note: Logback supports Groovy Script filter - but it is applicable only on specific appender configuration, not on Logger configuration.
Т.е. только фильтр и только на уровне аппендеров...

Lelouch, сейчас посмотрю второй тест.

Mayton,

Вот ещё про Full support:

https://github.com/INFINITE-TECHNOLOGY/BOBBIN/wiki/1---Introduction#full-support-for-scripting-in-logger-run-time-configuration-files

maytondakeirasпропущено...


В Бобине full support скриптинга в конфиге, все поля это скрипты:
- levels
- classes
- fileName
- format
и пр.

Partial из документации к Бобине:
пропущено...

Т.е. только фильтр и только на уровне аппендеров...
Но ты понимаешь что есть семантическое различие между конфигом и кодом?

В коде находят ошибки другого рода. Код сложнее тестировать. Код вообще
в общем случае корректен недоказуемо.

Конфиг - всегда корректен если просто прошел валидацию.

Ты, беря возможности Groovy перенёс часть логики в конфиги и выставил это как преимущество.
Но на самом деле это не разу не приемущество. Это - недостаток. Это - ненадёжность системы.

Вот. Прямо в точку.

Нет разницы между конфигом и кодом.

Есть единая система - с изменениями на этапах:
1) Сборки\компиляции
2) Запуска (старта) работы\перезапуске
3) В Runtime

Всё.

То что в конфигах не должны быть скрипты - это миф, страшилка родом из 90х.
Типа тормозит, небезопасно и пр. Это всё несостоятельно, и в результате приводит к декларативному программированию в конфигах ( https://github.com/INFINITE-TECHNOLOGY/BOBBIN/wiki/1---Introduction#declarative-programming-in-logger-configuration)
а также к изобретению волшебных синтаксисов.

А также типа пользователь не разберётся как настроить. Если дев опс не в состоянии осилить скрипт - он по определению не дев опс.