One interesting aspect is that JUL and Log4J allow practically the same notion and syntax in the code. Logger log = LogManager.getLogger(MyClass.class); This is a pattern all 3 logging frameworks (even Log4J 1 already offered it) have in common.
Doing so makes code fairly portable compared to using convenience methods like Logger log = Logger.getLogger(MyClass.class.getName()); Werner On Wed, Jan 7, 2015 at 7:13 PM, Werner Keil <[email protected]> wrote: > Exactly the idea was to minimize redundancies. > > If we agree the "pattern" of using JDK logging for (Java) clients and > "core" components, why not, then at least the other mature components would > use JUL. > For examples it's to harmonize it, as there has been a big difference even > between those already in place. Log4J 1 or SFL4J. That sounds too messy > even if each of them may "work" but it is a pain for people trying to use > examples having to configure logging of each in a different way. > > So I suggest > > - JUL for "client" components like classifier or simpleddr > - <To Be defined> for examples either > a) JUL, too > b) SLF4J or > c) ONE consistent version of Log4J among all of these examples > > Werner > > > > On Wed, Jan 7, 2015 at 6:56 PM, Reza Naghibi < > [email protected]> wrote: > >> Oops, sorry, I think I totally did just minimize this :) But my other >> points still stand... not broken, dont fix, feature creep, bloat. >> >> >> --- >> >> From: Reza Naghibi <[email protected]> >> To: "[email protected]" <[email protected]> >> Sent: Wednesday, January 7, 2015 12:45 PM >> Subject: Re: [DISCUSS] Logging in DeviceMap >> >> 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. >> > > >> > > >> > > >> > > >> > >> >> >> >> >> > >
