Christopher Tubbs resolved ACCUMULO-4812.
       Resolution: Not A Problem
         Assignee: Christopher Tubbs
    Fix Version/s:     (was: 2.0.0)

I analyzed the dependency tree for how these two jars are being used by 
Accumulo. We are not using them directly at all. They are both being brought in 
through the use of commons-configuration at compile time. commons-configuration 
has a direct dependency on commons-beanutils-core:1.8.0 and also an indirect 
dependency (via commons-digester:1.8) on commons-beanutils:1.7.0.

Since we're not using it directly, and we haven't seen a break as a result of 
this, I must conclude that whatever code paths we're using in 
commons-configuration, are such that it does not matter. However, it could 
still be an issue if any third party code is also using Accumulo's class path 
and needs one or the other.

Further, we're not shipping commons-beanutils at all in our assembly tarball... 
so if it's being used at all on the class path, it's being brought in through 
Hadoop or ZooKeeper's class path... and should be addressed by their packaging.

> Dependency Conflict: different Jars contain the incompatible classes with the 
> same name, which leads to NoSuchMethodException
> -----------------------------------------------------------------------------------------------------------------------------
>                 Key: ACCUMULO-4812
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4812
>             Project: Accumulo
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 2.0.0
>            Reporter: PandaMonkey
>            Assignee: Christopher Tubbs
>            Priority: Major
>              Labels: releasenotes
>         Attachments: Conflicting details.txt
> Hi,  by analyzing the accumulo-core:2.0.0-SNAPSHOT  
> accumulo-master\core\pom.xml file, we found that several duplicate classes 
> exist in different JARs: "commons-beanutils:commons-*beanutils-core*:1.8.0" 
> and "commons-beanutils:commons-*beanutils*:1.7.0". As the JVM only load the 
> classes present first on the classpath and shadow the other duplicate ones 
> with the same name. It would throw the "*NoSuchMethodException*" or 
> "*NoSuchMethodError*" if the duplicate classes are inconsistent! So we spend 
> some energy to scan the different features between these duplicate classes. 
> The conflicting details are listed in the attachment. Please pay attention to 
> it. Hope our report can help you. Thanks :).

This message was sent by Atlassian JIRA

Reply via email to