My answers are inline. On Wed, Jan 7, 2015 at 3:49 PM, Reza Naghibi <reza.nagh...@yahoo.com.invalid > wrote:
> Im going to say -1 unless there is something specific driving this. I dont > see anything below other than "Project X did a similar vote". So please > reply with reasons, requirements, concerns, etc. > Correct. My concerns are: > > -Its another 3rd party library dependency for a non core function. Logging > is not needed for the client to function properly. Im not against all 3rd > party dependencies. I use them all the time. But there needs to be solid > justification. > Can you please explain your reasons/requirements/concerns for using a library that has long been known for its deficiencies and avoid using one if its successors? The best part that I like about SLF4J is that it is a facade, not a concrete implementation, and does not try to be like one. I particularly believe that Apache DeviceMap also should not expose a concrete logger and let the application developer make his decision on how to log things. That is, you can use java.util.logging, Log4J, Logback, etc. with SLF4J. > -Users dont need logging and shouldnt have logging enabled. Its a > performance killer. Also, there is nothing in that log stream that can be > helpful to a user. If a user wants to goto the extreme and turn on logging, > the current logger can facilitate that. > I totally agree, that is why we need to use a facade and let the user make the decision to pick a concrete logger implementation to use. > -I would avoid forcing a logging framework on the project which uses this > library. > Using JUL already forces one. SLF4J will give a freedom of choice. > So I would look at how Spring does logging [0]. If anything, maybe detect > a logger and use it. But once again, thats going to be a performance hit > and I think some of my points will still hold regardless of the approach. > > [0] > http://docs.spring.io/spring-boot/docs/current/reference/html/howto-logging.html Yes, we should check what Spring does. An excerpt from Spring Framework Reference Documentation <http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#overview-logging> : Unfortunately, the runtime discovery algorithm in commons-logging, while convenient for the end-user, is problematic. If we could turn back the clock and start Spring now as a new project it would use a different logging dependency. The first choice would probably be the Simple Logging Facade for Java ( SLF4J), which is also used by a lot of other tools that people use with Spring inside their applications. Best.
