Объединение log4j.properties в библиотеке - плохой стиль или что?

Question

Я наткнулся на симпатичную небольшую инфраструктуру веб-запросов для Java: Spark . API выглядит красиво и многообещающе, но сам набор библиотек довольно странный. Оставьте в покое тот факт, что в качестве зависимостей предлагается использование артефактов моментальных снимков. Оставьте в покое тот факт, что он использует log4j для ведения журнала (в настоящее время библиотеки обычно используют jcl или slf4j), а иногда и System.out.println. Но он связывает свои собственные log4j.properties в spark-xxx.jar. Мне потребовался час, чтобы выяснить, почему мой проект будет жаловаться на конфигурацию log4j, когда log4j.properties определенно присутствует в моем classpath. -Dlog4j.debug = true дал ответ, log4j признался, что загрузил log4j.properties из спарочной банки.

Интересно, мотивируется ли это (быть библиотекой и использовать log4j и связывать log4j.properties) или это просто хромает.

Answer 1

Неправильно связывать свойства log4j.pro с библиотекой.

С помощью spark можно утверждать, что он ближе к серверу приложений (например, tomcat), и в этом случае он может настраивать ведение журнала.

Я бы сказал, что тест состоит в том, что тот, кто управляет сценарием запуска (.sh | .bat), должен настраивать ведение журнала, и что файлы конфигурации log4j почти никогда не должны находиться в банке.