[slf4j-user] Slf4j for Android

[Thorsten Möller]

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
dario.garcia at 10pines.com<mailto:dario.garcia at 10pines.com>

_______________________________________________
slf4j-user mailing list
slf4j-user at qos.ch<mailto:slf4j-user at qos.ch>
http://mailman.qos.ch/mailman/listinfo/slf4j-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-user/attachments/20120925/773b3305/attachment.html>