Bundling log4j.properties in a library - bad style or what?
I came across a nice small web request framework for Java: Spark. The API looks nice and promising, but the library bundle itself is pretty strange. Leave alone the fact that it proposes using sn开发者_如何学Goapshot artifacts as dependencies. Leave alone the fact that it uses log4j for logging (libraries tend to use jcl or slf4j nowadays), and System.out.println sometimes. But it bundles its own log4j.properties in spark-xxx.jar. It took me an hour to investigate why my project would complain of log4j configuration when log4j.properties is definitely present in my classpath. -Dlog4j.debug=true gave the answer, log4j confessed that it had loaded log4j.properties from spark jar.
I wonder if this (being a library and using log4j and bundling log4j.properties) has some motivation, or if it is just lame.
It is bad style to bundle a log4j.properties with a library.
With spark you could argue that it is closer to an app server (like tomcat) in which case it could configure logging.
I would say the test is that whoever controls the start(.sh|.bat) script should configure logging, and that log4j config files should almost never be in a jar.
精彩评论