Mailing-List: contact dev-help@devicemap.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@devicemap.apache.org
Received-SPF: pass (nike.apache.org: domain of werner.keil@gmail.com
 designates 209.85.218.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAGawe1+M7gqcMbfp9e56CocVFWBj06Lkn=NCLTFKAy833uM3Q@mail.gmail.com>
References: 
 <448819323.5950131.1420652746095.JavaMail.yahoo@jws106104.mail.bf1.yahoo.com>
	<20430441.5994099.1420653406513.JavaMail.yahoo@jws10623.mail.bf1.yahoo.com>
	<CAAGawe1+M7gqcMbfp9e56CocVFWBj06Lkn=NCLTFKAy833uM3Q@mail.gmail.com>
Date: Thu, 8 Jan 2015 00:03:31 +0100
Message-ID: 
 <CAAGawe3KbWyEgWvxDgHZW1SovW_3k1PHcAP6j_5-cUa1HXFsgg@mail.gmail.com>
Subject: Re: [DISCUSS] Logging in DeviceMap
From: Werner Keil <werner.keil@gmail.com>
To: dev@devicemap.apache.org
Content-Type: multipart/alternative; boundary=e89a8fb1fa7eb1826d050c17eee6

--e89a8fb1fa7eb1826d050c17eee6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

One interesting aspect is that JUL and Log4J allow practically the same
notion and syntax in the code.
Logger log =3D 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 =3D Logger.getLogger(MyClass.class.getName());

Werner

On Wed, Jan 7, 2015 at 7:13 PM, Werner Keil <werner.keil@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 wou=
ld
> use JUL.
> For examples it's to harmonize it, as there has been a big difference eve=
n
> 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 Log4=
J
>> 1.x in the POM and if it's not just for Spring or other libraries I gues=
s
>> 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=C4=B1c=C4=B1 <volkan.yazici@g=
mail.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=C4=B1c=C4=B1 <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 usin=
g
>> 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 logg=
er
>> > 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 use=
r
>> > make
>> > > the decision to pick a concrete logger implementation to use.
>> > >
>> > >
>> > > > -I would avoid forcing a logging framework on the project which us=
es
>> > 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 performan=
ce
>> > 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-logg=
ing.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/htm=
lsingle/#overview-logging
>> > > >
>> > > :
>> > >
>> > > Unfortunately, the runtime discovery algorithm in commons-logging,
>> while
>> > > convenient for the end-user, is problematic. If we could turn back t=
he
>> > > 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.
>> > >
>> > >
>> > >
>> > >
>> >
>>
>>
>>
>>
>>
>
>

--e89a8fb1fa7eb1826d050c17eee6--