devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Volkan Yazıcı <>
Subject Re: [DISCUSS] Logging in DeviceMap
Date Wed, 07 Jan 2015 15:53:11 GMT
My answers are inline.

On Wed, Jan 7, 2015 at 3:49 PM, Reza Naghibi <
> 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.


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]

Yes, we should check what Spring does. An excerpt from Spring Framework
Reference Documentation

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.


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