devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <werner.k...@gmail.com>
Subject Re: [DISCUSS] Logging in DeviceMap
Date Wed, 07 Jan 2015 18:13:33 GMT
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 <reza.naghibi@yahoo.com.invalid
> 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 <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