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.
> >
> >
> >
> >
>
