[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