Details
-
Improvement
-
Resolution: Unresolved
-
None
-
None
-
None
-
Operating System: other
Platform: Other
-
enhancement
-
P3
-
231
Description
The SLF4J Android port should provide means to completely turn of logging (for performance reasons, for production use). This issue is intended primarily for discussing the different options for a solution.
There are at least three ways how it could be achieved:
First, by deactivating all logging related method calls when compiling an application. Obviously, this would be tedious if done manually and should therefore be automated by some kind of scripting and be part of the build process.
Second, by a "null" logger implementation that can be used instead of the standard one (which delegates to Android Log). The downside here is that logging is not entirely deactivated since the application code is compiled unchanged, hence, there is still (more or less) logging overhead. Also, the question is how should we switch between the two: programmatically or externally configurable?
A third option is to distribute two different JARs, one for debugging purposes, another one for production use. The difference between the two JARs is that the former contains the standard logger, while the latter contains a null logger. This would be easily integratable in a Maven-managed build process: one can define two profiles, say "dev" and "rel". The latter would define a dependency using a classifier referring to the null-logger JAR whereas the former would define a dependency to the JAR containing the default logger. However, this approach has the same downside than the second one.
Attachments
Activity
(In reply to comment #2)
I don't know... I don't use Maven for my projects, and I've never run into a case where the logs would add so much overhead that they would need to be totally removed (actually yes, but not on Android).
Anyway, I'm not part of slf4j team, but I guess the use of maven goes far beyond the scope of this bugzilla...
The intention is not to add this as new functionality to slf4j-android (nor the slf4j-api). The current Android binding should remain as simple as possible; that is, simply delegate to the Android logger. I'm rather in favor of build-time configuration solutions (rather than file-based configuration since they require extending the current binding).
I agree that the Progard solution is elegant (and falls into the first type of solutions sketched in my initial description of this issue).
One possibility that comes to mind is to add the maven-proguard-plugin to the build process such that a "noop" JAR is created (whose name includes a additional classifier such as "noop") in which all invocations of methods on android.util.Log are removed, including debug and verbose. Projects that use slf4j-android could then use Maven profiles to select either the standard JAR (for development) or the "noop" JAR (for production use). There is even more control available for advanced users by modification of the Proguard "assumenosideeffects" parameter; i.e., one can build a JAR in which all logging calls except error are removed.
The reason why including debug and verbose in the "noop" JAR makes sense is that they are "... are compiled in but stripped at runtime ..."; hence, there is still some overhead at runtime.
What do you think?
Hi,
I'm also interested in your point, but I don't really get it, since :
- Android removes VERBOSE & DEBUG logs at runtime (http://developer.android.com/reference/android/util/Log.html).
- you can select lines to remove from your code with proguard, like (example with native Android log API, adapt for slf4j) :
-assumenosideeffects class android.util.Log {
public *** v(...);
public *** d(...);
public *** println(...);
=> is it a feature missing in slf4j android or do you want it global to slf4j or ... ?
(In reply to comment #3)
> (In reply to comment #2)
> Anyway, I'm not part of slf4j team, but I guess the use of maven goes far beyond
> the scope of this bugzilla...
Well, Maven is already used by slf4j-android. So it boils down to a simple extension of the POM, which I have already done locally to test it. However, there is an issue with Proguard that has to be sorted out first (it doesn't seem to be happy with the Android JARs that are available from Maven Central).