[slf4j-user] SLF4J on the Google Android Platform
Thorsten.Moeller at unibas.ch
Thorsten.Moeller at unibas.ch
Wed Mar 3 14:00:17 CET 2010
Chiao,
thanks for your comments and suggestions (I'm the one who created
slf4j-android).
I will come back to this next week since I'm currently out of office.
Cheers,
Thorsten
Quoting Chiao Cheng <zimazenini at yahoo.com>:
> Hi All,
>
> I was playing around with android and was glad to see that someone
> already put together a slf4j-android module. I tried using it and I
> really like to make some changes so I created another fork.
>
> First, I found an old thread explaining why slf4j-android also
> includes slf4j-api code...
>
>> I can already tell you that I needed to merge the SLf4J-API project and
>> the new binding implementation into one (Maven) project. The reason is
>> rather complicated to explain. In short, it is due to the fact that
>> SLF4J API removes the dummy impl.* classes during the build from the
>> target Jar, which is not compatible with the Android DexerI'm not
>> sure why this would be the case because the dexer is completely ok
>> with dex'ing multiple jars and dependencies. I suggest we separate
>> out slf4j-api code from the slf4j-android module. Once we do
>> this, then it would be easier to keep the two in sync. With the
>> current setup, it seems like it would be very easy for
>> slf4j-android to fall out of sync with the main api version. And
>> from the web page, it seems like it has already fallen behind. I
>> made the appropriate changes (basically stripping out all
>> slf4j-api code from slf4j-android directory) in my fork and it
>> seems to work just fine. I've tested using android platform 1.6+.
>
> Next, I found a problem in the recent access modifier changes in
> slf4j. Specifically the references from LoggerFactory to private
> StaticLoggerBinder.SINGLETON. Even though the java runtime seems to
> be ok due to shortcircuit logic I'm guessing, the android runtime
> is not:
>
> "access denied from Lorg/slf4j/LoggerFactory; to field
> Lorg/slf4j/impl/StaticLoggerBinder;.SINGLETON"
>
> For now, I had to change StaticLoggerBinder.SINGLETON back to public
> to avoid these errors. But, from looking at the code, I do not see
> any reasons for LoggerFactory to reference
> StaticLoggerBinder.SINGLETON, other than allowing some modules to
> work without a getSingleton() method. But I would love to remove
> SINGLETON references in the LoggerFactory. Also seems a bit hacky
> to have code that tries to access private members. Are there plans
> to get rid of the SINGLETON references completely?
>
> Finally the only other change I made was to remove the systempath in
> the pom.xml. Users can simply install a 3rd party jar in their
> local repository with the provided maven command so there is really
> no need to have that. And to make things simpler, there is already
> an android-maven-plugin which will install the jars for you in your
> local-repository
> (http://code.google.com/p/maven-android-plugin/wiki/GettingStarted).
>
> Anyways, my fork is currently working so take a look
> (http://github.com/chiao/slf4j). But it would be nice to get the
> changes into the main trunk to keep up with updates.
>
> Cheers,
> Chiao
> _______________________________________________
> slf4j-user mailing list
> slf4j-user at qos.ch
> http://qos.ch/mailman/listinfo/slf4j-user
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
More information about the slf4j-user
mailing list