I've prepared https://github.com/apache/jena/pull/28 to fix most of the below.

On 10 February 2015 at 10:41, Andy Seaborne <[email protected]> wrote:

> SLF4J: Class path contains multiple SLF4J bindings.
> logging/pax-logging-api/1.8.1/pax-logging-api-1.8.1.jar
> org/slf4j/slf4j-log4j12/1.7.6/slf4j-log4j12-1.7.6.jar
>
> -----------------------------------
> which may explain why test/resources/log4j.properties is ignored.

I struggled with the logging, I must admit that bit of PAX I didn't
understand. If I didn't add the pax logging modules, and tried to load
slf4j-logj4 directly, it would complain about slf4j-log4j being a
'fragment bundle' (this is a PAX+Felix constraint, it seems) - and
without it then jena-osgi won't start as it definitely needs some
org.slf4j implementation.

I looked at https://ops4j1.jira.com/wiki/display/paxexam/Logging+Configuration

All the documentation about PAX logging seems to send you towards
logback -  which I stayed away from to not complicate the picture even
more!


> Should slf4j be excluded?

Some org.slf4j bundle must be there - otherwise Jena will not be
happy. If we stick with the pax-logging-api (being unable to figure
out this fragment bundle prroblem),  slf4j-log4j should ideally be
excluded.

The problem is that it is inherited from jena-parent.. Ways around this:

a) Change jena-parent. But everyone else probably want slf4j-log4j (at
least for <scope>test ?)
b) Don't use jena-parent in this particular module (uh..)
c) Find out how to get rid of the pax-logging and only use
slf4j-logging (I tried for 1.5 hour without luck..)
d) Just leave the warning in there.. I've added a comment to the pom
in the pull request.


> -Dorg.ops4j.pax.logging.DefaultServiceLog.level=WARN from the command line
> works but is impractical ... which plugin does it need to be set on?  And
> how?

I think it would be part of the junit tests, so the normal
maven-surefire-plugin. This worked:

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>
          <systemPropertyVariables>
            
<org.ops4j.pax.logging.DefaultServiceLog.level>WARN</org.ops4j.pax.logging.DefaultServiceLog.level>
          </systemPropertyVariables>
        </configuration>
      </plugin>

.. except for the noise about duplicate slf4j binding, obviously.

Fixed in pull request #28.


> There is an OSGi test failure:
>
> https://builds.apache.org/user/andy/my-views/view/Jena/job/Jena_Development_Test/org.apache.jena$jena-osgi-test/1750/testReport/
>
> which I followed back to:
>
> Caused by: org.sonatype.aether.resolution.VersionRangeResolutionException:
> Not highest version found for org.apache.jena:jena-osgi:jar:(0.0,]

I can reproduce this.

Fixed in pull request #28 - system property to the rescue here as well.

(I didn't want to hardcode 2.13.0-SNAPSHOT in the test - but I think
it can only find LATEST if you've done mvn install of jena-osgi)




Log output of mvn verify is now much, much shorter:

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running org.apache.jena.osgi.test.JenaOSGITest
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/home/stain/.m2/repository/org/ops4j/pax/logging/pax-logging-api/1.8.1/pax-logging-api-1.8.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/home/stain/.m2/repository/org/slf4j/slf4j-log4j12/1.7.6/slf4j-log4j12-1.7.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type
[org.ops4j.pax.logging.slf4j.Slf4jLoggerFactory]

Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.78
sec - in org.apache.jena.osgi.test.JenaOSGITest

Results :

Tests run: 4, Failures: 0, Errors: 0, Skipped: 0



and I verified that if I broke the test, you still get the errors. :)
You would have to uncomment the org.ops4j.pax.logging property to find
out whatever went wrong in bundle loading though.

-- 
Stian Soiland-Reyes, eScience Lab
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/    http://orcid.org/0000-0001-9842-9718

Reply via email to