On Monday, August 23, 2010 10:51 PM [GMT+1=CET], Darrin Edelman <[email protected]> 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 > [email protected] > http://qos.ch/mailman/listinfo/slf4j-dev _______________________________________________ slf4j-dev mailing list [email protected] http://qos.ch/mailman/listinfo/slf4j-dev
