[morphia] Logging

9 views
Skip to first unread message

Uwe Schäfer

unread,
May 21, 2010, 7:24:36 AM5/21/10
to mor...@googlegroups.com
hi

i am used to use log statements in my code. in most of out projects, and
the libs we use, slf4j is used in order not to force a particular
logging fw on the user, and i consider it good practice.

i see direct usage of jdk-logging currently in morphia, which i consider
a problem. in a perfect world, i´d like to add a dependency to slf4j-api
and a jdk-logging binding for test-scope.

fine for you?

cu uwe


Ólafur Gauti Guðmundsson

unread,
May 21, 2010, 7:29:33 AM5/21/10
to mor...@googlegroups.com
Hi,
The use of jdk logging was to keep dependencies to a minimum. This was one of the objectives when creating the project: keeping it lightweight and with a minimal set of dependencies.

I personally use slf4j in my projects, but the question is: does the benefit of using that in Morphia outweigh the added dependency?

Regards,
OGG

2010/5/21 Uwe Schäfer <u...@thomas-daily.de>

Uwe Schäfer

unread,
May 21, 2010, 8:21:04 AM5/21/10
to mor...@googlegroups.com
Ólafur Gauti Guðmundsson schrieb:

Hi Olafur,

> The use of jdk logging was to keep dependencies to a minimum. This was
> one of the objectives when creating the project: keeping it lightweight
> and with a minimal set of dependencies.

i see and appreciate that kind of spirit.

> I personally use slf4j in my projects, but the question is: does the
> benefit of using that in Morphia outweigh the added dependency?

imho, absolutely, yes!

as a user of a lib, i am constantly p*ssed off by a lib forcing its
decisions for cross-cutting concerns (like logging) on me.

example: personally, i use log4j and remote-logging to be able to plug
into a running application and trace it. with all the building blocks of
my app using slf4j, i can happily do so. if one of these decided to keep
it simple by choosing JDK-Logging for me, it made it hard to impossible
to get the information together.

using this facade and letting the user decide is imho good practice and
a common decision of plenty of other libs facing the exact same
challenge/trade-off.

cu uwe

Ólafur Gauti Guðmundsson

unread,
May 21, 2010, 8:44:22 AM5/21/10
to mor...@googlegroups.com
Hi Uwe,
Good point, I agree. Adding slf4j is fine by me.

Regards,
OGG

2010/5/21 Uwe Schäfer <u...@thomas-daily.de>
Ólafur Gauti Guðmundsson schrieb:

Scott Hernandez

unread,
May 21, 2010, 10:12:08 AM5/21/10
to mor...@googlegroups.com
2010/5/21 Uwe Schäfer <u...@thomas-daily.de>:
> Ólafur Gauti Guðmundsson schrieb:
>
> Hi Olafur,
>
>> The use of jdk logging was to keep dependencies to a minimum. This was one
>> of the objectives when creating the project: keeping it lightweight and with
>> a minimal set of dependencies.
>
> i see and appreciate that kind of spirit.

I'm in agreement that slf4j is a good api, but the dependency and
configuration requirements seem a bit much. I use slf4j, and have it
configured (in my app) as my bridge for both commons-logging and
log4j, outputting to JUL.

>> I personally use slf4j in my projects, but the question is: does the
>> benefit of using that in Morphia outweigh the added dependency?
>
> imho, absolutely, yes!
>
> as a user of a lib, i am constantly p*ssed off by a lib forcing its
> decisions for cross-cutting concerns (like logging) on me.
>
> example: personally, i use log4j and remote-logging to be able to plug into
> a running application and trace it. with all the building blocks of my app
> using slf4j, i can happily do so. if one of these decided to keep it simple
> by choosing JDK-Logging for me, it made it hard to impossible to get the
> information together.

That is simply not true. At this point it is just a matter of using
the slf4j bridging jars to do this.
http://www.slf4j.org/legacy.html

There is performance overhead, but only if you enable a considerable
amount of logging (which probably would only be in situations for
debugging).

> using this facade and letting the user decide is imho good practice and a
> common decision of plenty of other libs facing the exact same
> challenge/trade-off.

Yes, that is true. It is sometimes hard to balance your logging
configuration needs and keep down deps. But I can also think of very
few log statements that we generate that will not be used for
debugging (only). Most things which cause errors cause exceptions and
are not logged as the means to document them (and I hope this pattern
only continues).

> cu uwe

Uwe Schäfer

unread,
May 21, 2010, 10:44:58 AM5/21/10
to mor...@googlegroups.com
Scott Hernandez schrieb:

hi Scott,

oh, you´re right with that bridge. i did not even know that (for i did
not need it yet)

> That is simply not true. At this point it is just a matter of using
> the slf4j bridging jars to do this.
> http://www.slf4j.org/legacy.html
> There is performance overhead,

a significant one, i might add ;)

> It is sometimes hard to balance your logging
> configuration needs and keep down deps. But I can also think of very
> few log statements that we generate that will not be used for
> debugging (only).

you´re basically saying, keep the number of warnings low and don´t log
for debugging purposes?

i find that rather strange, given that the "configuration need" is
actually not there.
if a user does not provide a binding, logging will be just disabled.

nevertheless, i wont fight for it.

> Most things which cause errors cause exceptions and
> are not logged as the means to document them (and I hope this pattern
> only continues).

agreed for errors. that´s where i find the current validation scheme
rather strange, but to that in another mail... :)

cu uwe

--
THOMAS DAILY GmbH
Adlerstraße 19
79098 Freiburg
Deutschland
T + 49 761 3 85 59 0
F + 49 761 3 85 59 550
E scha...@thomas-daily.de
www.thomas-daily.de

Geschäftsführer/Managing Directors:
Wendy Thomas, Susanne Larbig
Handelsregister Freiburg i.Br., HRB 3947


Registrieren Sie sich unter https://www.thomas-daily.de/user/sign-in für
die TD Morning News, eine kostenlose Auswahl aktueller Themen aus TD
Premium, morgens ab 9:15 in Ihrer Mailbox.

Aktuelle Presseinformationen für die TD Morning News und TD Premium
nimmt unsere Redaktion unter reda...@thomas-daily.de entgegen.
Redaktionsschluss für die TD Morning News ist täglich um 8:45.

Register free of charge at https://www.thomas-daily.de/user/sign-in to
have the TD Morning News, a selection of the latest topics from TD
Premium, delivered to your mailbox from 9:15 every morning.

Our editorial department receives the latest press releases for the TD
Morning News and TD Premium at reda...@thomas-daily.de. The editorial
deadline for the TD Morning News is 8.45am daily.

Scott Hernandez

unread,
May 21, 2010, 10:53:02 AM5/21/10
to mor...@googlegroups.com
2010/5/21 Uwe Schäfer <u...@thomas-daily.de>:
> Scott Hernandez schrieb:
>
> hi Scott,
>
> oh, you´re right with that bridge. i did not even know that (for i did not
> need it yet)
>
>> That is simply not true. At this point it is just a matter of using
>> the slf4j bridging jars to do this.
>> http://www.slf4j.org/legacy.html
>> There is performance overhead,
>
> a significant one, i might add ;)

Yes (based on the volume of converted messages), see below.

>> It is sometimes hard to balance your logging
>> configuration needs and keep down deps. But I can also think of very
>> few log statements that we generate that will not be used for
>> debugging (only).
>
> you´re basically saying, keep the number of warnings low and don´t log for
> debugging purposes?

No, I'm saying in production environments limit the actual debugging.
If you need to debug, and it will hopefully not be in production, turn
on more logging and take the perf. hit.

Remember, those number are in terms of % of logging time, not app
time. 20% more logging overhead can be significant, but if logging is
only 5% (overhead) of you app then you are only talking about 6%
total, even with the inefficiencies of the bridge.

> i find that rather strange, given that the "configuration need" is actually
> not there.
> if a user does not provide a binding, logging will be just disabled.
>
> nevertheless, i wont fight for it.

Fight away; I'm just saying there is a significant overhead to going
from 0 deps, to 1 (logging).

>> Most things which cause errors cause exceptions and
>>
>> are not logged as the means to document them (and I hope this pattern
>> only continues).
>
> agreed for errors. that´s where i find the current validation scheme rather
> strange, but to that in another mail... :)

Indeed.

> cu uwe
Reply all
Reply to author
Forward
0 new messages