[slf4j-dev] slf4j on the google android platform

[Darrin Edelman]

Thorsten -

That's a nice solution - sounds perfect.

What of the other two points below :
2. Where is this sourcecode?  Am I missing this in Git somehow?
3. Are there plans to get slf4j-android into a maven repo?

Thanks,
-Darrin

I didn't see this in the android code base - have I missed something?  What 
On Aug 24, 2010, at 4:52 AM, Thorsten Möller wrote:

> 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 
> 
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev at qos.ch
> http://qos.ch/mailman/listinfo/slf4j-dev