You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@devicemap.apache.org by Werner Keil <we...@gmail.com> on 2015/01/07 12:49:35 UTC
[DISCUSS] Logging in DeviceMap
Hi,
This is one of the two development-side aspects I'd like to discuss, given
it was also raised in the Tamaya list (they are still incubating but try to
sort such things out at an earlier stage;-)
As of now we have at least 2, sometimes up to 3 ways of logging.
- java.util.logging (mainly used by java-client/classifier alone)
- log4j 1.2.17 (used by many examples web-apps especially those for
classifier)
- slf4j (though I think I caught most of it and replaced with log4j 2
which offers an equally clean separation of API and Impl as SLF4J does)
We should try to consolidate this further. I am totally unbiased, maybe we
can just do a simple vote (like Tamaya PMC) in a "+1 for X" style?
Cheers,
Werner
Re: [DISCUSS] Logging in DeviceMap
Posted by Reza Naghibi <re...@yahoo.com.INVALID>.
Sure. And im totally with you, SLF4J is the best option for configurable logging.
So I guess my next question would be, why does an application owner need to see the logging in the client? Im not sure of any usecase which would justify it. Even for error reporting, all we need is the client version, data version and the input string. If there was a need, JUL is configurable for those cases [0].
[0] http://docs.oracle.com/cd/E19717-01/819-7753/gcblo/index.html
From: Volkan Yazıcı <vo...@gmail.com>
To: "dev@devicemap.apache.org" <de...@devicemap.apache.org>; Reza Naghibi <re...@yahoo.com>
Sent: Wednesday, January 7, 2015 11:38 AM
Subject: Re: [DISCUSS] Logging in DeviceMap
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 <re...@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ı <vo...@gmail.com>
To: "dev@devicemap.apache.org" <de...@devicemap.apache.org>; Reza Naghibi <re...@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.
Re: [DISCUSS] Logging in DeviceMap
Posted by Werner Keil <we...@gmail.com>.
One interesting aspect is that JUL and Log4J allow practically the same
notion and syntax in the code.
Logger log = LogManager.getLogger(MyClass.class);
This is a pattern all 3 logging frameworks (even Log4J 1 already offered
it) have in common.
Doing so makes code fairly portable compared to using convenience methods
like
Logger log = Logger.getLogger(MyClass.class.getName());
Werner
On Wed, Jan 7, 2015 at 7:13 PM, Werner Keil <we...@gmail.com> wrote:
> 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 <re...@yahoo.com.INVALID>
>> To: "dev@devicemap.apache.org" <de...@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 <we...@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ı <vo...@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ı <vo...@gmail.com>
>> > > To: "dev@devicemap.apache.org" <de...@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.
>> > >
>> > >
>> > >
>> > >
>> >
>>
>>
>>
>>
>>
>
>
Re: [DISCUSS] Logging in DeviceMap
Posted by Werner Keil <we...@gmail.com>.
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 <re...@yahoo.com.INVALID>
> To: "dev@devicemap.apache.org" <de...@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 <we...@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ı <vo...@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ı <vo...@gmail.com>
> > > To: "dev@devicemap.apache.org" <de...@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.
> > >
> > >
> > >
> > >
> >
>
>
>
>
>
Re: [DISCUSS] Logging in DeviceMap
Posted by Reza Naghibi <re...@yahoo.com.INVALID>.
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 <re...@yahoo.com.INVALID>
To: "dev@devicemap.apache.org" <de...@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 <we...@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ı <vo...@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ı <vo...@gmail.com>
> > To: "dev@devicemap.apache.org" <de...@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.
> >
> >
> >
> >
>
Re: [DISCUSS] Logging in DeviceMap
Posted by Reza Naghibi <re...@yahoo.com.INVALID>.
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 <we...@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ı <vo...@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ı <vo...@gmail.com>
> > To: "dev@devicemap.apache.org" <de...@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.
> >
> >
> >
> >
>
Re: [DISCUSS] Logging in DeviceMap
Posted by Werner Keil <we...@gmail.com>.
Mark responded:
>slf4j ist ok für end user applications, aber ich würde es nicht für
frameworks einsetzen. Das gibt immer wieder ClassLoader clashes wenn
mehrere apps verschiedene >Versionen davon parallel verwenden. Bei JUL hast
das nicht.
>Einen riesen Vorteil hat Log4j gegenüber JUL aber: es unterstützt MDC
(mapped diagnostic context). Das ist ein killerfeature! Aber du kannst ja
Log4j ohne große Probleme >auch als backend für jul verwenden. Wenn also
frameworks jul als API verwenden dann ist das ok. Keine external
dependency und garantiert keine classpath clashes. Für >consumer apps bzw
als logging backend ist JUL allerdings suboptimal
Some (Eberhard, Bertrand only little) may understand German, so I leave his
original reply.
Interpreting it for "framework" which would include all clients he suggests
JUL could be better, for "applications" e.g. examples either Log4J or SLF4J
(backed by any preferred solution) would be better.
WDYT?
On Wed, Jan 7, 2015 at 6:01 PM, Werner Keil <we...@gmail.com> wrote:
> 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ı <vo...@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ı <vo...@gmail.com>
>> > To: "dev@devicemap.apache.org" <de...@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.
>> >
>> >
>> >
>> >
>>
>
>
Re: [DISCUSS] Logging in DeviceMap
Posted by Werner Keil <we...@gmail.com>.
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ı <vo...@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ı <vo...@gmail.com>
> > To: "dev@devicemap.apache.org" <de...@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.
> >
> >
> >
> >
>
Re: [DISCUSS] Logging in DeviceMap
Posted by Volkan Yazıcı <vo...@gmail.com>.
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ı <vo...@gmail.com>
> To: "dev@devicemap.apache.org" <de...@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.
>
>
>
>
Re: [DISCUSS] Logging in DeviceMap
Posted by Reza Naghibi <re...@yahoo.com.INVALID>.
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ı <vo...@gmail.com>
To: "dev@devicemap.apache.org" <de...@devicemap.apache.org>; Reza Naghibi <re...@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.
Re: [DISCUSS] Logging in DeviceMap
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Jan 7, 2015 at 4:53 PM, Volkan Yazıcı <vo...@gmail.com> wrote:
>
> ...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?...
You guys might be talking about different things.
$ cd devicemap/java/classifier
$ mvn dependency:tree
...
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ devicemap-client ---
[INFO] org.apache.devicemap:devicemap-client:jar:1.1.1-SNAPSHOT
[INFO] +- org.apache.devicemap:devicemap-data:jar:1.0.2-SNAPSHOT:test
[INFO] \- junit:junit:jar:4.11:test
[INFO] \- org.hamcrest:hamcrest-core:jar:1.3:test
I don't see any logging dependency there, I guess that's Reza's point.
-Bertrand
Re: [DISCUSS] Logging in DeviceMap
Posted by Werner Keil <we...@gmail.com>.
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ı <vo...@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.
>
Re: [DISCUSS] Logging in DeviceMap
Posted by Volkan Yazıcı <vo...@gmail.com>.
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.
Re: [DISCUSS] Logging in DeviceMap
Posted by Reza Naghibi <re...@yahoo.com.INVALID>.
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.
-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 would avoid forcing a logging framework on the project which uses this library.
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
---
From: Volkan Yazıcı <vo...@gmail.com>
To: "dev@devicemap.apache.org" <de...@devicemap.apache.org>
Sent: Wednesday, January 7, 2015 6:56 AM
Subject: Re: [DISCUSS] Logging in DeviceMap
+1 for SLF4J.
I am also volunteer for migrating all the existing Java logging routines to
SLF4J.
On Wed, Jan 7, 2015 at 12:49 PM, Werner Keil <we...@gmail.com> wrote:
> Hi,
>
> This is one of the two development-side aspects I'd like to discuss, given
> it was also raised in the Tamaya list (they are still incubating but try to
> sort such things out at an earlier stage;-)
>
> As of now we have at least 2, sometimes up to 3 ways of logging.
>
> - java.util.logging (mainly used by java-client/classifier alone)
> - log4j 1.2.17 (used by many examples web-apps especially those for
> classifier)
> - slf4j (though I think I caught most of it and replaced with log4j 2
> which offers an equally clean separation of API and Impl as SLF4J does)
>
> We should try to consolidate this further. I am totally unbiased, maybe we
> can just do a simple vote (like Tamaya PMC) in a "+1 for X" style?
>
> Cheers,
>
> Werner
>
Re: [DISCUSS] Logging in DeviceMap
Posted by Volkan Yazıcı <vo...@gmail.com>.
+1 for SLF4J.
I am also volunteer for migrating all the existing Java logging routines to
SLF4J.
On Wed, Jan 7, 2015 at 12:49 PM, Werner Keil <we...@gmail.com> wrote:
> Hi,
>
> This is one of the two development-side aspects I'd like to discuss, given
> it was also raised in the Tamaya list (they are still incubating but try to
> sort such things out at an earlier stage;-)
>
> As of now we have at least 2, sometimes up to 3 ways of logging.
>
> - java.util.logging (mainly used by java-client/classifier alone)
> - log4j 1.2.17 (used by many examples web-apps especially those for
> classifier)
> - slf4j (though I think I caught most of it and replaced with log4j 2
> which offers an equally clean separation of API and Impl as SLF4J does)
>
> We should try to consolidate this further. I am totally unbiased, maybe we
> can just do a simple vote (like Tamaya PMC) in a "+1 for X" style?
>
> Cheers,
>
> Werner
>