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. > > > >
