[slf4j-dev] slf4j on the google android platform

[Thorsten Möller]

On Monday, August 23, 2010 10:51 PM [GMT+1=CET],
Darrin Edelman <darrin501 at gmail.com> wrote (with possible deletions):

> I did get slf4j-android working after going through the list here by
> grabbing the source code and patching it myself but I'm wondering if
> progress has been made on the issues below so that I can adopt a more
> official release?
The repository [1] contains a fix which simply truncates names longer 
than 23 characters at the right-hand side. This fix is considered a 
temporary solution and it is intended to eventually come up either with 
the solution proposed in comment #10 [2], or with the following solution 
(inspired by Eclipse IDE which has a similar function):

tag = a.package.name.longer.than.twentythree.characters.MyClass

would be shortened to

tag = a.p*.n*.l*.t*.t*.c*.MyClass

If tag would still be longer than 23 characters (e.g. long class name, 
deep hierarchy, or no dots at all), then one could further shorten it to

tag = *TrailOfLongClassName


Feedback welcome as well as patches. I suggest to continue the 
discussion via Bugzilla directly on the issue.


Cheers,
Thorsten


[1] http://github.com/twwwt/slf4j
[2] http://bugzilla.slf4j.org/show_bug.cgi?id=173#c10






> Thanks in advance,
> -Darrin
>
>>>
>>> I've run into a couple frustrating issues with slf4j-android
>>> that you're no doubt aware of as it seems that some work has
>>> occurred
>>> here:
>>>
>>> 1) http://bugzilla.slf4j.org/show_bug.cgi?id=173
>>>
>>> Given that I'm dealing with a cross-platform library with lots of
>>> existing code the '23 character' android limit is a showstopper for
>>> me. I cannot change all the library code to use 'simplename' for
>>> example.  Granted I see this as really an issue with Android - but
>>> still we should be able to handle this in the android port.  This
>>> means that I cannot just handle it in the android specific portions
>>> of the code - the already written libraries have to properly deal
>>> with this issue by cropping the name of the logger - so that the
>>> library functions don't throw exceptions.  This to me means that I
>>> need to change the StaticLoggerBinder to instantiate a version of
>>> code that knows how to deal with this issue properly even when the
>>> client code isn't aware of it.  Wendel's solution in the above
>>> thread
>>> seems a reasonable solution.
>>>
>>> 2) Availability of android source-code from repo.
>>>
>>> Given that this is an for me issue I'd like to put the fix in that
>>> wendell suggest... use as much of the useful name as possible and
>>> hopefully
>>> Android comes around and fixes this limitation someday.   I grabbed
>>> the codebase from git and I couldn't find references to the android
>>> branch.  Specifically it seems like wendell's fix is a decent
>>> work-around for the android limitation.  Unfortunately I cannot
>>> easily do this and contribute any branches back to the open source
>>> community because I cannot seem to find android code in this
>>> branch.  Now
>>> this said - I did find the slf4j-android code base on the website
>>> so I can move forward... but why isn't this in Git??
>>>
>>> 3) Really just a picky thing... slf4j-android does not appear to be
>>> available from any publicly accessible maven repository.
>>>
>>> I've resolved this by adding the jar to my project and automatically
>>> deploying it to the local repo - but this really isn't a very
>>> elegant solution.  Any chance the android version is going to be
>>> made available anytime soon?  I'd rather not package the jar as a
>>> build
>>> artifact.
>
>>
>
>
>
>
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev at qos.ch
> http://qos.ch/mailman/listinfo/slf4j-dev