Hi Dario,

comments inlined ...


Am 25.09.2012 um 17:07 schrieb Dario Garcia:

Hi everyone,

This is my first post, I apologize if not conforming to the etiquette of this 
list (point me in the right direction in that case).

My name is Darío García, I'm an Android developer using SLF4J Android.
I have a little suggestion for SLF4J Android that will make my life easier, and 
hopefully other users too.

The context:
My android application use several libs that output log statements using slf4j.
As far as I know there's no way to tell the Android SLF4J binding which loggers 
should be silent and which should be outputed (as oposed to logback's 
configuration xml).

One can control this via the facilities provided by android.util.Log, because 
the binding that is part of slf4j-andoird simply delegates all log calls to 
this class. Have a look at its documentation [1]. The relevant part is 
explained in the section on the method isLoggable(...). In short, you have to 
set a system property for each tag that you want to configure (yes, it's not 
that convenient if it has to be done for many different tags).

That means that when I set debug as the current level, I get mixed statements 
from my code, and from those libraries in the log and is difficult to read.
Also there's a performance penalty due to all the logging.

Suggestion 1:
Is there any chance that you will be adding the possibility to configure each 
logger as logback does?
No. If you want full flexibility then I recommend using logback-android instead 
(as indicated by another e-mail in this thread). The idea of slf4j-android is 
to provide means to delegate log requests issued via the SLF4J API to the 
Android logging facilities. The intention was not to provide a fully fledged 
logging solution (rather a quick and simple way to integrate SLF4J with the 
Android logging framework, to be used mainly at development time rather than in 
production).

I could mute the libraries and only output my own code to android logcat.

Alternate suggestion 2:
Is there any chance to separate the SLF4J api, and the android binding?

I was pondering about this question several times already. At the moment, I 
don't see a clean solution. The main reason is that the build process on the 
Android platform differs from "normal" platforms in the fact that there is an 
additional step - the Dexer (that optimizes the bytecode). Because of this, the 
static binding used by SLF4J does no longer work and would have to be replaced 
either by a dynamic binding at runtime or, which is what is done currently in 
slf4j-android, by providing the binding at build time (in order to get the 
Dexer happy).

In that way I could use a Null Binding for those libraries so I don't see them 
in the logs.

A similar thing is planned for the next release. There is a noop binding ready 
for the next release. If used then any log request becomes a noop. This is not 
exactly what you are requesting, but experience shows that one often wants 
logging at development time, while at production time one rather aims at 
performance. The idea is to decide at build time whether the standard binding 
(that delegates to android.util.Log) or the noop binding is to be used, by 
generating two different JARs. An application can then switch between these two 
versions at build time (e.g., if Maven is used then one could create two 
profiles - debug and release).


Cheers,
Thorsten



[1] http://developer.android.com/reference/android/util/Log.html



And use the native android logging system for my own code.
This is not as pretty but could do the work.

Thanks for your time,
Best regards

--
Darío García
Agile Software Development
+54 (911) 6336-3707
Office: +54 - 011 - 4311-8404
[email protected]<mailto:[email protected]>

_______________________________________________
slf4j-user mailing list
[email protected]<mailto:[email protected]>
http://mailman.qos.ch/mailman/listinfo/slf4j-user

_______________________________________________
slf4j-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-user

Reply via email to