Sure. And im totally with you, SLF4J is the best option for configurable logging.
So I guess my next question would be, why does an application owner need to see the logging in the client? Im not sure of any usecase which would justify it. Even for error reporting, all we need is the client version, data version and the input string. If there was a need, JUL is configurable for those cases [0]. [0] http://docs.oracle.com/cd/E19717-01/819-7753/gcblo/index.html From: Volkan Yazıcı <[email protected]> To: "[email protected]" <[email protected]>; Reza Naghibi <[email protected]> Sent: Wednesday, January 7, 2015 11:38 AM Subject: Re: [DISCUSS] Logging in DeviceMap Deficiency: Say I have an application X that employs devicemap-client and uses Log4J for logging. Now the application owner needs to configure logging for both Log4J and JUL. The driver is that: As a library we should not make any assumptions on the used logging framework implementation. On Wed, Jan 7, 2015 at 5:10 PM, Reza Naghibi <[email protected]> wrote: Ok, you made some points. I still have a few questions: Can you explain some of the known deficiencies for java.util.logging? Also, again, what is the requirement driving this where the user needs to have better logging configuration and access? From: Volkan Yazıcı <[email protected]> To: "[email protected]" <[email protected]>; Reza Naghibi <[email protected]> Sent: Wednesday, January 7, 2015 10:53 AM Subject: Re: [DISCUSS] Logging in DeviceMap My answers are inline. On Wed, Jan 7, 2015 at 3:49 PM, Reza Naghibi <[email protected] > 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.
