Dependency Conflict: duplicate classes "org.jboss.security.Util" in different JARs, have different implementations

[HelloCoCooo]

Hi, in jss7-8.0.0-179 (\management\shell-server-impl module), duplicate classes with the same fully-qualified name org.jboss.security.Util are included in two different libraries, i.e., org.jboss.jbossas:jboss-as-security:5.1.0.GA and org.picketbox:picketbox:4.9.6.Final.

According to "first declaration wins" class loading strategy, only this class in org.jboss.jbossas:jboss-as-security:5.1.0.GA can be loaded, and that in org.picketbox:picketbox:4.9.6.Final will be shadowed.

By further analyzing, your project expects to invoke method <org.jboss.security.Util: char[] loadPassword(java.lang.String)> in org.picketbox:picketbox:4.9.6.Final. As it has been shadowed, so that this method defined in org.jboss.jbossas:jboss-as-security:5.1.0.GA is actually forced to be referenced via the following invocation path:

<org.restcomm.ss7.management.console.ShellServer: void stop()> D:\testcase\TestProject\jss7-8.0.0-179\management\shell-server-impl\target\classes
<org.infinispan.util.CloseableSuppliedIterator: boolean hasNext()> D:\cEnvironment\repository\org\infinispan\infinispan-core\8.2.4.Final\infinispan-core-8.2.4.Final.jar
<org.infinispan.util.CloseableSuppliedIterator: java.lang.Object getNext()> D:\cEnvironment\repository\org\infinispan\infinispan-core\8.2.4.Final\infinispan-core-8.2.4.Final.jar
<org.infinispan.persistence.util.PersistenceManagerCloseableSupplier: java.lang.Object get()> D:\cEnvironment\repository\org\infinispan\infinispan-core\8.2.4.Final\infinispan-core-8.2.4.Final.jar
<org.infinispan.persistence.util.PersistenceManagerCloseableSupplier: org.infinispan.container.entries.CacheEntry get()> D:\cEnvironment\repository\org\infinispan\infinispan-core\8.2.4.Final\infinispan-core-8.2.4.Final.jar
<org.wildfly.clustering.service.AsynchronousServiceBuilder$1: void run()> D:\cEnvironment\repository\org\wildfly\wildfly-clustering-service\10.1.0.Final\wildfly-clustering-service-10.1.0.Final.jar
<org.jboss.as.security.service.SecurityVaultService: void start(org.jboss.msc.service.StartContext)> D:\cEnvironment\repository\org\wildfly\wildfly-security\10.1.0.Final\wildfly-security-10.1.0.Final.jar
<org.picketbox.plugins.vault.PicketBoxSecurityVault: void init(java.util.Map)> D:\cEnvironment\repository\org\picketbox\picketbox\4.9.6.Final\picketbox-4.9.6.Final.jar
<org.picketbox.plugins.vault.PicketBoxSecurityVault: char[] loadKeystorePassword(java.lang.String,java.lang.String,int)> 
<org.jboss.security.Util: char[] loadPassword(java.lang.String)>

Although both of these two conflicting classes contain the referenced methods (with the same signature), they have different implementations. This issue will not lead to runtime crashes, but it can introduce inconsistent semantic hehavior by changing the control flows and data flows.

Workaround solution:
An easy way to workaround the problem is reversing the declaration order of these two libraries in pom file.
Then, according to "first declaration wins" class loading strategy, class org.jboss.security.Util in org.picketbox:picketbox:4.9.6.Final can be loaded (the version that RestComm/jss7 expects to reference by static analysis).
This fix will not affect other libraries or class, except the above duplicate class.

Dependency tree--
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ shell-server-impl ---
[INFO] org.restcomm.protocols.ss7.management:shell-server-impl:jar:8.0.0-179
[INFO] +- org.restcomm.protocols.ss7.management:shell-server-api:jar:8.0.0-179:compile
[INFO] +- org.restcomm.protocols.ss7.management:shell-transport:jar:8.0.0-179:compile
[INFO] +- log4j:log4j:jar:1.2.14:provided
[INFO] +- javolution:javolution:jar:5.5.1:compile
[INFO] +- org.restcomm.protocols.ss7.scheduler:scheduler:jar:8.0.0-179:compile
[INFO] +- org.jboss.jbossas:jboss-as-security:jar:5.1.0.GA:provided
[INFO] | +- javassist:javassist:jar:3.9.0.GA:provided
[INFO] | +- org.jboss.security:jboss-security-spi:jar:2.0.3.SP1:provided
[INFO] | +- org.jboss.security:jbosssx:jar:2.0.3.SP1:provided
[INFO] | +- org.jboss:jboss-common-core:jar:2.2.14.GA:provided
[INFO] | | - org.jboss.logging:jboss-logging-spi:jar:2.1.0.GA:provided
[INFO] | +- org.jboss.jbossas:jboss-as-system-jmx:jar:5.1.0.GA:provided
[INFO] | | +- apache-xerces:xml-apis:jar:2.9.1:provided
[INFO] | | +- org.jboss:jboss-vfs:jar:2.1.2.GA:provided
[INFO] | | +- org.jboss:jbossxb:jar:2.0.1.GA:provided
[INFO] | | | +- wutka-dtdparser:dtdparser121:jar:1.2.1:provided
[INFO] | | | +- javax.activation:activation:jar:1.1:provided
[INFO] | | | - sun-jaxb:jaxb-api:jar:2.1.9-brew:provided
......
[INFO] +- org.jboss.security:jboss-negotiation-spnego:jar:3.0.2.Final:provided
[INFO] +- org.picketbox:picketbox:jar:4.9.6.Final:provided
[INFO] +- org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec:jar:1.0.0.Final:provided
[INFO] | - org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final:provided
[INFO] +- org.picketbox:picketbox-infinispan:jar:4.9.6.Final:provided
[INFO] +- org.picketbox:picketbox-commons:jar:1.0.0.final:provided
[INFO] +- commons-cli:commons-cli:jar:1.2:provided
[INFO] - org.wildfly.checkstyle:wildfly-checkstyle-config:jar:1.0.4.Final:provided

Thank you very much.
Best,
Coco

[HelloCoCooo]

Code snippet of :<org.jboss.security.Util: char[] loadPassword(java.lang.String)> in org.jboss.jbossas:jboss-as-security:5.1.0.GA (loaded version):

Code snippet of :<org.jboss.security.Util: char[] loadPassword(java.lang.String)> in org.picketbox:picketbox:4.9.6.Final
(shadowed but expected to invoke method):

As a result, these conflicting method included in org.picketbox:picketbox:jar:4.9.6.Final deals with different cases, which changes the control flows and data flows. So being forced to use these methods in org.jboss.jbossas:jboss-as-security:5.1.0.GA may lead to inconsisitent semantic behaviors.