Dashboard showing linkage errors in commons-logging:commons-logging:1.2

[suztomo]

Part of #1863

https://storage.googleapis.com/cloud-opensource-java-dashboard/com.google.cloud/libraries-bom/16.1.0/com.google.http-client_google-http-client_1.38.0.html#linkage-errors

3 linkage error(s)

commons-logging:commons-logging:1.2
3 target classes causing linkage errors referenced from 3 source classes.

Class org.apache.avalon.framework.logger.Logger is not found, referenced from org.apache.commons.logging.impl.AvalonLogger

Class org.apache.log.Hierarchy is not found, referenced from org.apache.commons.logging.impl.LogKitLogger

Class org.apache.log.Logger is not found, referenced from org.apache.commons.logging.impl.LogKitLogger

The following paths contain commons-logging:commons-logging:1.2: ▼

com.google.cloud:google-cloud-bigquery:1.124.7 (compile) / commons-logging:commons-logging:1.2 (compile)
com.google.cloud:google-cloud-compute:0.119.0-alpha (compile) / commons-logging:commons-logging:1.2 (compile)
com.google.cloud:google-cloud-dns:1.0.5 (compile) / commons-logging:commons-logging:1.2 (compile)

Are they really problematic? If not we should not show them in the dashboard.

AvalonLogger

Javadoc: AvalongLogger

Implementation of commons-logging Log interface that delegates all logging calls to the Avalon logging abstraction: the Logger interface.

https://avalon.apache.org/closed.html says

Apache Avalon has closed.

commons-logging:1.2 declares avalong-framework as optional:

    <dependency>
      <groupId>avalon-framework</groupId>
      <artifactId>avalon-framework</artifactId>
      <version>4.1.5</version>
      <optional>true</optional>
    </dependency>

Maven does not include transitive optional dependencies. I don't see org.apache.commons.logging.impl.AvalonLogger catches NoClassDefFoundError to see the availability.

LogKitLogger

Javadoc: LogKitLogger:

Implementation of org.apache.commons.logging.Log that wraps the avalon-logkit logging system.

The class has 2 invalid references: org.apache.log.Hierarchy and org.apache.log.Logger. Both classes are in logkit artifact. As per the Javadoc above, the logkit is part of the Avalon project.

commons-logging:1.2 declares the dependency as optional.

    <dependency>
      <groupId>logkit</groupId>
      <artifactId>logkit</artifactId>
      <version>1.0.1</version>
      <optional>false</optional>
    </dependency>

Maven does not include transitive optional dependencies. I don't see org.apache.commons.logging.impl.LogKitLogger catches NoClassDefFoundError to see the availability.

Are they reachable? No, they are not reachable from the artifacts in the Libraries BOM.

[elharo]

Why are they declared optional? How does commons-logging react when they're not in the classpath?

[suztomo]

Why are they declared optional?

Because not all commons-logging users need Avalon and Logkit.

How does commons-logging react when they're not in the classpath?

I didn't find any reference to the AvalonLogger or LogkitLogger from other classes in commons-logging. As per commons-logging documentation on its configuration, commons-logging users specify underlying logger implementation through commons-logging.properties, in which users can specify concrete class names such as org.apache.commons.logging.impl.AvalonLogger and org.apache.commons.logging.impl.LogKitLogger. I couldn't find the exact class names in commons-logging documents, probably because Avalon project had been closed when commons-logging 1.2 was released in 2014.

[elharo]

Surprisingly this project doesn't seem to be dormant. We should send an issue and PR to them to remove Avalon and possibly LogKitLogger if they have not already done so.

[suztomo]

Sure. Let me file and issue and a pull request for commons-logging.

Filed: https://issues.apache.org/jira/browse/LOGGING-173

Memo

The last issue that mention avalon was 2013 https://issues.apache.org/jira/browse/LOGGING-143

[suztomo]

@elharo Do you think it's a bad idea to show only reachable errors in the dashboard? I think the references to the unused logger classes are typical use cases for the reachability check.

[suztomo]

Discussed with Elliotte.

The entry point classes are the BOM members. How the suppressing unreachable linkage errors affect those who use declare dependencies to the transitive dependencies of BOM project?

It's better to suppress specific linkage errors rather than suppressing many unknowns.

Google-http-java-client's dependency comes from apache-http-client 4. The apache-http-client 5 does not depends on commons-logging.

Flattening the published pom.xml makes it difficult to identify where commons-logging:commons-logging:1.2 is used in the BOM.

Old libraries BOM version 1.0.0 shows we depend commons-logging only through

• com.google.http-client:google-http-client:1.29.1 (compile) / org.apache.httpcomponents:httpclient:4.5.5 (compile) / commons-logging:commons-logging:1.2 (compile)
• com.google.http-client:google-http-client-apache:2.1.0 (compile) / org.apache.httpcomponents:httpclient:4.5.5 (compile) / commons-logging:commons-logging:1.2 (compile)

https://storage.googleapis.com/cloud-opensource-java-dashboard/com.google.cloud/libraries-bom/1.0.0/com.google.cloud_google-cloud-bigquery_1.66.0.html

[elharo]

This is fixed, right?

[suztomo]

The errors are still there