search

RestComm / jss7

RestComm Java SS7 Stack and Services
http://www.restcomm.com/
GNU Affero General Public License v3.0
191 stars 224 forks source link

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

Open HelloCoCooo opened 5 years ago

HelloCoCooo commented 5 years ago

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 commented 5 years ago

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): 111 222

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): 333

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.