Последний вопрос не в кассу, это же groovy.

dakeirasLelouchdakeiras,

if (httpRequest.method == "POST") { <-- я понимаю, что это работает, так как "POST" интернируется, но почему не equals?

Груви код, там надо == писать. По умолчанию == в Груви это equals.

http://docs.groovy-lang.org/latest/html/documentation/core-operators.html#_identity_operator

да, я уже понял, постом выше.

application.config стоит поправить:

dakeirasLelouchdakeiras,

1) Зачем каждый раз пересоздавать SslContext?
2) Зачем использовать глобальные настройки SslSocketFactory? (Любой другой код, соседствующий с этой библиотекой и использующий HttpsUrlConnection может вести себя неожидано)
3) Зачем каждый раз пересоздавать обертку для отправки запросов?

По вопросу №1 - SSLContext.getInstance("TLS") - это разве не Singletone?
Без шуток, если честно особо не глядел.

Если нет, поправлю. Не надо так делать.

По вопросу №2 - это standalone приложение, оно не подразумевает размещение на общем сервере приложений с другими.
Именно по причине глобалього defaultSSLSocketFactory.

Какие есть альтернативы setDefaultSSLSocketFactory?

По вопросу №3 - это отлично подмеченно. Поправлю.
1) В java 8 и 11 нет.
2) У вас каждый outputQueue имеет собственную настройку senderClassName . Использование SenderDefaultHttps и SenderDefaultHttpsUnsecure для разных очередей приведет к гонке на defaultSSLSocketFactory. Можно использовать HttpsUrlConnection#setSocketFactory

dakeirasА вот то что нет скачиваний Bobbin - вот это неожиданно...

ну я бы тоже не стал его использовать.
Как минимум:
1) заявление о производительности, но 0 бенчмарков
2) только синхронные аппендеры
3) отсутсвие возможности перенастроить уровень логирования в runtime.
4) Необходимость тащить за логгером 5мб зависимости в виде groovy (logback например - 2 зависимости суммарно 800кб)
5) Малое количество доступных аппендеров
6) меня терзают смутные сомнения о FileDestination - КМК каждый поток может создать свой FileWriter для каждого файла и попробовать что-то туда записать. Что при этом будет с содержимым файла?

7) любой exception в Destination#store просто свалит поток, вызвавший логирование...

dakeiras,

что в них, простите, асинхронного? store явно вызывает FileWriter#write

dakeiras,

Это асинхронным его не делает. Кроме этого ОЧЕНЬ усложняет анализ логов.
+ Не могли бы вы показать, где к имени файла примешивается идентификатор потока?

dakeiras,

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

dakeiras,

Если я правильно понял, то на уровне конфигурации:
"fileName": "\"./LOGS/${threadName}/${level}/${threadName}_${level}_${date}.log\"",

при этом если пользователь НЕ укажет threadName при настроке навзания или пути файла - то видимо он ССЗБ :) прэлэстно

vas0,

ThreadLocal