Binding log4j.properties in a library - bad style or what?

Question

I came across a beautiful web query structure for Java: Spark . The API looks nice and promising, but the library set itself is rather strange. Leave alone the fact that he suggests using snapshot artifacts as dependencies. Leave alone the fact that it uses log4j for logging (libraries usually use jcl or slf4j at present) and System.out.println sometimes. But it binds its own log4j.properties in spark-xxx.jar. It took me an hour to figure out why my project would complain about the log4j configuration when log4j.properties is definitely present in my classpath. -Dlog4j.debug = true gave the answer, log4j admitted that he downloaded log4j.properties from the spark can.

I wonder if this (being a library and using log4j and binding log4j.properties) has some motivation, or if it is just lame.

Answer 1

Bad style for linking log4j.properties to the library.

With a spark, you can claim that it is closer to the application server (e.g. tomcat), in which case it can configure logging.

I would say that the test is that the one who controls the launch of the (.sh | .bat) script should configure the logging, and the log4j configuration files should almost never be in the bank.