Mark responded: >slf4j ist ok für end user applications, aber ich würde es nicht für frameworks einsetzen. Das gibt immer wieder ClassLoader clashes wenn mehrere apps verschiedene >Versionen davon parallel verwenden. Bei JUL hast das nicht.
>Einen riesen Vorteil hat Log4j gegenüber JUL aber: es unterstützt MDC (mapped diagnostic context). Das ist ein killerfeature! Aber du kannst ja Log4j ohne große Probleme >auch als backend für jul verwenden. Wenn also frameworks jul als API verwenden dann ist das ok. Keine external dependency und garantiert keine classpath clashes. Für >consumer apps bzw als logging backend ist JUL allerdings suboptimal Some (Eberhard, Bertrand only little) may understand German, so I leave his original reply. Interpreting it for "framework" which would include all clients he suggests JUL could be better, for "applications" e.g. examples either Log4J or SLF4J (backed by any preferred solution) would be better. WDYT? On Wed, Jan 7, 2015 at 6:01 PM, Werner Keil <[email protected]> wrote: > 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. >> > >> > >> > >> > >> > >
