devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reza Naghibi <reza.nagh...@yahoo.com.INVALID>
Subject Re: [DISCUSS] Logging in DeviceMap
Date Wed, 07 Jan 2015 17:56:46 GMT
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 <reza.naghibi@yahoo.com.INVALID>
 To: "dev@devicemap.apache.org" <dev@devicemap.apache.org> 
 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 <werner.keil@gmail.com>


 To: dev@devicemap.apache.org 
 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ı <volkan.yazici@gmail.com>
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
> <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