[slf4j-dev] [Bug 173] slf4j android: Android throws an IllegalArgumentException when Log Tag length exceeds 23 characters

[bugzilla-daemon at qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=173

--- Comment #16 from idolon <idolon.dev at gmail.com> ---
> (In reply to comment #14)
> > Taking into account my comment above, maybe we should relax the tag length
> > limitation from 23 to at least 80?
> Don't agree because it makes things more difficult. How would "is...Enabled"
> methods be implemented then: delegate to the backing Android "isLoggable"
> logger method? No longer possible directly because they would throw IAE if
> tag length > 23. Extend the AndroidLogger such that it implements its own
> logic on this? Possible, but, first, it makes it more heavyweight, which,
> recalling the original design goal of having the most simple adapter between
> SLF4J and AndroidLogging, breaks this goal.
> 
> I would really love to see the limitation issue being solved at Android side
> rather than working around it.

At first I wished to write that the issue would *never* be solved on the
existing devices, only in the upcoming Android versions and bla-bla-bla. 
But then I asked myself why for the hell that checks for 23 characters exists
at all? And only in "Log.isLoggable" method. So I've dug a little bit deeper
into the source code and reread the documentation carefully (yeah, I should
have done this before posting my first comment here), and that's what I've
realized: 

1) "Log.isLoggable: checks to see whether or not a log for the specified tag is
loggable at the specified level. The default level of any tag is set to INFO
... You can change the default level by setting a system property: 
setprop log.tag.<YOUR_LOG_TAG> <LEVEL>"

2) But system property name can't exceed 32 character including terminating
'\0'
http://androidxref.com/4.3_r2.1/xref/system/core/include/cutils/properties.h#31

3) Taking into account p.1 and p.2 we can safely conclude that for ALL tag
lengths > 23 "AndroidLogger.isTraceEnabled" and "isDebugEnabled" should return
"false", and all others "is...Enabled" should return "true".

Do you see what I mean?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-dev/attachments/20130911/6d553344/attachment.html>