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 16:04:07 GMT
While not quoting all of the discussion in Tamaya, the point was not to do
it as they (or any other Apache project;) did, but to CONSOLIDATE it here.

Mark, both Mentor of Tamaya and former PMC chair of DeltaSpike had some
concerns related to SLF4J, and they were more general, not specific to a
particular project. I'd have to ask him what it was.

So far all examples especially the ones for Classifier use Log4J 1.x
directly while the actual client uses JUL.
If we keep that separation between clients and examples, why would we do
that?

If all of them used JUL (or something else) I have no strong preference,
but ideally we should use as few deviations as possible, at least for each
language (.NET or JavaScript are not affected as they may have another
dependency chain)

Cheers,
Werner


On Wed, Jan 7, 2015 at 4:53 PM, Volkan Yazıcı <volkan.yazici@gmail.com>
wrote:

> 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