I just want to point out that this discussion is a bit of a bikeshed [0]. I am in no way trying to minimize this or end discussion, but my usual stance is if it isnt broken, dont fix it. Something I want to avoid is bloat and feature creep.
[0] http://bikeshed.com/ From: Werner Keil <[email protected]> To: [email protected] Sent: Wednesday, January 7, 2015 12:01 PM Subject: Re: [DISCUSS] Logging in DeviceMap That's a valid point, which is why ideally they might be consistent. If they're consistent to be all JUL, that might be better than 2 or 3 different ones. The classifier EXAMPLES devicemap/examples (at least dmap-servlet and dmap-spring) point to Log4J 1.x in the POM and if it's not just for Spring or other libraries I guess the examples also use it. Some other examples used either Log4J 1 or SLF4J, too which I unified to be Log4J 2. Ideally all examples could use the same logging API and even better if the clients did, too. Werner On Wed, Jan 7, 2015 at 5:38 PM, Volkan Yazıcı <[email protected]> wrote: > 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. > > > > > > > > >
