jnaerator includes slf4j API and also its implementation

[GoogleCodeExporter]

> What steps will reproduce the problem?

1. build some application that includes jnaerator and slf4j logging
2. try to provide logging through log4j using slf4j-log4j12 implementation
3. try to configure logging using log4j.properties

> What is the expected output? What do you see instead?

I expect the application reads log4j.properties and logs according to it.
The jnaerator hijacks all the logging and routes it through jdk14 logging
system. log4j.properties is ignored.

> What version of the product are you using? On what operating system?

0.9.1, but i see 0.9.2 does the same.

> Please provide any additional information below.

I would expect that jnaerator.jar comes only with its own classes, and it
gets other dependencies using its pom.xml. 

Including slf4j implementation together with the library jar misses the
main point of slf4j. It is meant that the libraries use only the API jar
(slf4j-api) and depend only on it. The application developer chooses which
implementation to use and include only that specific implementation.

Original issue reported on code.google.com by andrius....@mif.vu.lt on 11 Nov 2009 at 8:11

[GoogleCodeExporter]

Hi Andrius,

Thanks for your report...
I guess to fix that I need to twinker with Rococoa's pom and/or add some 
exclusion 
clause to JNAerator's... Stay tuned :-)

Cheers

Original comment by olivier.chafik@gmail.com on 11 Nov 2009 at 1:44

• Changed state: Accepted

[GoogleCodeExporter]

Fixed in revision #895 and latest 0.9.3-SNAPSHOT binaries.
Thanks again :-)

Original comment by olivier.chafik@gmail.com on 21 Nov 2009 at 1:31

• Changed state: Fixed

[GoogleCodeExporter]

The slf4j is still included with JNAerator. The problem is that the version 
included is 1.5.8 which is old. I have a project which depends on slf4j-1.6. If 
JNAerator is before the slf4j-api-1.6.1.jar in the classpath the slf4j from 
JNAerator is loaded and breaks the code. Is it really necessary to include 
slf4j within JNAerator? Can this be solved with an external dependency?

Thanks and keep up the good work!

Original comment by darko.ce...@gmail.com on 27 Sep 2011 at 4:04