NOTICE! This is a static HTML version of a legacy LOCI Software ticket.

LOCI projects are now located on GitHub. The Bio-Formats project can be found here.

Ticket #481 (closed defect: fixed)

Opened 2010-03-22T19:02:18-05:00

Last modified 2010-07-13T16:58:30-05:00 does not detect that unit tests depend upon log4j JARs

Reported by: melissa Owned by: melissa
Priority: trivial Milestone: bio-formats-4.2
Component: build Severity: minor
Keywords: Cc:
Blocked By: Blocking:


Several of the tests in the 'common' and 'bio-formats' components fail if slf4j-api-1.5.10.jar and/or log4j-12-1.5.10.jar are not in the classpath. However, does not detect that these JARs are required, and so will print a warning if the are added to the classpath, e.g.

Dependency mismatch for LOCI Common compile time classpath:
  project deps        =
  library deps        = slf4j-api testng
  component.classpath = ${lib.dir}/slf4j-api-1.5.10.jar ${lib.dir}/slf4j-log4j12-1.5.10.jar ${lib.dir}/log4j-1.2.15.jar ${lib.dir}/testng-5.11-jdk15.jar

Dependency mismatch for LOCI Common runtime classpath:
  project deps         =
  reflected projects   =
  library deps         = slf4j-api testng
  reflected libraries  =
  component.runtime-cp = ${lib.dir}/slf4j-api-1.5.10.jar ${lib.dir}/slf4j-log4j12-1.5.10.jar ${lib.dir}/log4j-1.2.15.jar ${lib.dir}/testng-5.11-jdk15.jar

Change History

comment:1 Changed 2010-03-31T17:20:59-05:00 by curtis

  • Status changed from new to closed
  • Resolution set to fixed

Fixed in r6085.

First of all, slf4j-log4j12-1.5.10.jar and log4j-1.2.15.jar are not actually needed to compile the LOCI Common package—they are only used at runtime. So if they are specified in at all, they should be specified in component.runtime-cp rather than component.classpath.

Secondly, slf4j-api-1.5.10.jar does not have a proper ClassPath entry in its manifest (due to the agnosticism of its logging API), so the dependent JARs do not get loaded unless they are explicitly set on the classpath. (That said, the log4j JARs are not actually "dependent"—see the  slf4j manual for details.)

As a consequence, to use loci-common.jar with log4j, it must have three log4j-related JARs in its runtime classpath, even though two of them are "dependencies of a dependency," which violates good dependency chaining practices.

To work around, I added lines to one of the LOCI Common classes noting that slf4j-log4j12-1.5.10.jar and log4j-1.2.15.jar are used via reflection, which tricks into a successful dependency matching.

However, the fact is that loci-common.jar does not specifically need slf4j-log4j12-1.5.10.jar and log4j-1.2.15.jar in its runtime classpath at all—any one slf4j binding will do. One thing I did not verify is what happens if NO such binding is present on the classpath. Will classes like loci.common.Location still load, or must there be at least slf4j-nop-1.5.11.jar on the classpath?

We should discuss our policy with respect to the slf4j logging framework, as it introduces non-trivial dependency problems at every level of our codebase.

comment:2 Changed 2010-07-09T12:55:02-05:00 by melissa

  • Milestone bio-formats-4.2 deleted

Milestone bio-formats-4.2 deleted

comment:3 Changed 2010-07-13T16:58:30-05:00 by melissa

  • Milestone set to bio-formats-4.2