-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dependency conflicts on commons-codec:commons-codec, leading to inconsistent program behaviors #4
Comments
Executing the following test case on commons-codec:commons-codec:1.3 and 1.4 separately, the risky method <org.apache.commons.codec.binary.Base64: decode([B)[B> will get different return values: @Test(timeout = 4000)
public void test01() throws Throwable {
Base64 base64 = new Base64();
byte[] byteArray0 = new byte[]{(byte) 53, (byte) 67, (byte) 83};
byte[] byteArray1 = base64.decode(byteArray0);
assertEquals(3, byteArray1.length);
} Output results: byteArray1.length == 3 //On **commons-codec:commons-codec:1.3**
byteArray1.length == 2 //On **commons-codec:commons-codec:1.4** Variable token (defined in class org.apache.http.impl.auth.NegotiateScheme of library org.apache.httpcomponents:httpclient:jar:4.1.3) is assigned by the return value of method <org.apache.commons.codec.binary.Base64: decode([B)[B>. As such, token's value would be changed when the client project references commons-codec:commons-codec:1.3 (compared with the shadowed but expected version 1.4), which could affect program semantic behaviors. /** code snippet of class org.apache.http.impl.auth.NegotiateScheme of library org.apache.httpcomponents:httpclient:jar:4.1.3 **/
private byte[] token;
@Override
protected void parseChallenge(
final CharArrayBuffer buffer,
int beginIndex, int endIndex) throws MalformedChallengeException {
String challenge = buffer.substringTrimmed(beginIndex, endIndex);
if (log.isDebugEnabled()) {
log.debug("Received challenge '" + challenge + "' from the auth server");
}
if (state == State.UNINITIATED) {
token = new Base64().decode(challenge.getBytes());
state = State.CHALLENGE_RECEIVED;
} else {
log.debug("Authentication already attempted");
state = State.FAILED;
}
} |
@groves Could please help me check this issue? |
Issue description
Hi, in metrics-cloudwatch-master, there are mulptiple versions of library commons-codec:commons-codec. However, according to Maven's dependency management strategy: "first declaration wins", only commons-codec:commons-codec:1.3 can be loaded, and commons-codec:commons-codec:1.4 will be shadowed.
As shown in the following figure, your project expects to invoke method <org.apache.commons.codec.binary.Base64: decode([B)[B> in library commons-codec:commons-codec:1.4 (along the original dependency path). As it has been shadowed, this method defined in commons-codec:commons-codec:1.3 is actually forced to be referenced via the following invocation path (along the actual dependency path):
Although both of these conflicting libraries contain the referenced methods (with the same signature), they have different implementations. This issue will not cause runtime crashes, but it can introduce inconsistent semantic program hehaviors----
Code snippet of <org.apache.commons.codec.binary.Base64: decode([B)[B> in commons-codec:commons-codec:1.4 (shadowed but expected to invoke method):
detailed method body
Code snippet of <org.apache.commons.codec.binary.Base64: decode([B)[B> in commons-codec:commons-codec:1.3 (loaded version):
detailed method body
Dependency tree--
[INFO] com.plausiblelabs.metrics:metrics-cloudwatch:jar:2.1.2.3-SNAPSHOT
[INFO] +- com.yammer.metrics:metrics-core:jar:2.1.2:compile
[INFO] | - (org.slf4j:slf4j-api:jar:1.6.4:compile - omitted for duplicate)
[INFO] +- com.amazonaws:aws-java-sdk:jar:1.3.14:compile
[INFO] | +- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] | +- (org.apache.httpcomponents:httpclient:jar:4.1:compile - omitted for conflict with 4.1.3)
[INFO] | +- commons-codec:commons-codec:jar:1.3:compile
[INFO] | +- org.codehaus.jackson:jackson-core-asl:jar:1.8.9:compile
[INFO] | - org.codehaus.jackson:jackson-mapper-asl:jar:1.8.9:compile
[INFO] | - (org.codehaus.jackson:jackson-core-asl:jar:1.8.9:compile - omitted for duplicate)
[INFO] +- org.slf4j:slf4j-api:jar:1.6.4:compile
[INFO] +- org.apache.httpcomponents:httpclient:jar:4.1.3:compile
[INFO] | +- org.apache.httpcomponents:httpcore:jar:4.1.4:compile
[INFO] | +- (commons-logging:commons-logging:jar:1.1.1:compile - omitted for duplicate)
[INFO] | - (commons-codec:commons-codec:jar:1.4:compile - omitted for conflict with 1.3)
[INFO] +- org.slf4j:slf4j-jdk14:jar:1.6.4:test
[INFO] | - (org.slf4j:slf4j-api:jar:1.6.4:test - omitted for duplicate)
[INFO] +- com.yammer.metrics:metrics-core:test-jar:tests:2.1.2:test
[INFO] | - (org.slf4j:slf4j-api:jar:1.6.4:test - omitted for duplicate)
[INFO] +- junit:junit:jar:4.4:test
[INFO] - com.google.guava:guava:jar:11.0.2:test
[INFO] - com.google.code.findbugs:jsr305:jar:1.3.9:test
Suggested solutions:
Solution1: Remove the conflicting Jars.
Solution2: Declare version commons-codec:commons-codec:1.4 as a direct dependency, to override the version 1.3 (based on Maven's nearest wins loading strategy).
Solution3: reversing the declaration order of these two libraries in pom file.
Thanks.
Best regards,
Coco
The text was updated successfully, but these errors were encountered: