devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Volkan Yazıcı <volkan.yaz...@gmail.com>
Subject Re: [DISCUSS] Logging in DeviceMap
Date Wed, 07 Jan 2015 16:38:30 GMT
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 <reza.naghibi@yahoo.com.invalid
> 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ı <volkan.yazici@gmail.com>
>  To: "dev@devicemap.apache.org" <dev@devicemap.apache.org>; Reza Naghibi <
> reza.naghibi@yahoo.com>
>  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
> <reza.naghibi@yahoo.com.invalid
> > 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.
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message