You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 30, 2020. It is now read-only.
Hi, in hazelcast-jet-code-samples-0.7.2 (hazelcast-jet-code-samples-0.7.2\integration\pcf module), duplicate classes with the same fully-qualified name org.apache.log4j.PropertyConfigurator are included in two different libraries, i.e., log4j:log4j:1.2.12 and org.slf4j:log4j-over-slf4j:1.7.22.
According to "first declaration wins" class loading strategy, only this class in org.slf4j:log4j-over-slf4j:1.7.22 can be loaded, and that in log4j:log4j:1.2.12 will be shadowed.
By further analyzing, your project expects to invoke methods----
(1) <org.apache.log4j.PropertyConfigurator: void doConfigure(java.lang.String,org.apache.log4j.spi.LoggerRepository)>
(2) org.apache.log4j.PropertyConfigurator: void doConfigure(java.net.URL,org.apache.log4j.spi.LoggerRepository)>
(3) org.apache.log4j.PropertyConfigurator: void doConfigure(java.util.Properties,org.apache.log4j.spi.LoggerRepository)>
in log4j:log4j:1.2.12. As they has been shadowed, so that these methods defined in org.slf4j:log4j-over-slf4j:1.7.22 are actually forced to be referenced via the following invocation path (taking <org.apache.log4j.PropertyConfigurator: void doConfigure(java.lang.String,org.apache.log4j.spi.LoggerRepository)> for example):
Although both of these two conflicting classes contain the referenced methods (with the same signature), they have different implementations. This issue will lead to inconsistent semantic hehavior by changing the control flows and data flows.
Workaround solution:
The 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.apache.log4j.PropertyConfigurator in log4j:log4j:1.2.12 can be loaded (the version that hazelcast-jet-code-samples expects to reference by static analysis).
This fix will not affect other libraries or class, except the above duplicate class.
Code snippet of the above conflict methods in org.slf4j:log4j-over-slf4j:jar:1.7.22:compile (loaded version):
Code snippet of the above conflict methods in log4j:log4j:jar:1.2.12:compile (shadowed but expected to invoke method):
As a result, these conflicting method included in org.slf4j:log4j-over-slf4j:jar:1.7.22:compile have no concrete implementations, which changes the control flows and data flows of invocation context. So that being forced to use these methods in org.slf4j:log4j-over-slf4j:jar:1.7.22:compile may lead to inconsisitent semantic behaviors.
Hi, in hazelcast-jet-code-samples-0.7.2 (hazelcast-jet-code-samples-0.7.2\integration\pcf module), duplicate classes with the same fully-qualified name org.apache.log4j.PropertyConfigurator are included in two different libraries, i.e., log4j:log4j:1.2.12 and org.slf4j:log4j-over-slf4j:1.7.22.
According to "first declaration wins" class loading strategy, only this class in org.slf4j:log4j-over-slf4j:1.7.22 can be loaded, and that in log4j:log4j:1.2.12 will be shadowed.
By further analyzing, your project expects to invoke methods----
(1) <org.apache.log4j.PropertyConfigurator: void doConfigure(java.lang.String,org.apache.log4j.spi.LoggerRepository)>
(2) org.apache.log4j.PropertyConfigurator: void doConfigure(java.net.URL,org.apache.log4j.spi.LoggerRepository)>
(3) org.apache.log4j.PropertyConfigurator: void doConfigure(java.util.Properties,org.apache.log4j.spi.LoggerRepository)>
in log4j:log4j:1.2.12. As they has been shadowed, so that these methods defined in org.slf4j:log4j-over-slf4j:1.7.22 are actually forced to be referenced via the following invocation path (taking <org.apache.log4j.PropertyConfigurator: void doConfigure(java.lang.String,org.apache.log4j.spi.LoggerRepository)> for example):
Although both of these two conflicting classes contain the referenced methods (with the same signature), they have different implementations. This issue will lead to inconsistent semantic hehavior by changing the control flows and data flows.
Workaround solution:
The 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.apache.log4j.PropertyConfigurator in log4j:log4j:1.2.12 can be loaded (the version that hazelcast-jet-code-samples 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) @ pcf ---
[INFO] com.hazelcast.jet.samples:pcf:jar:0.7.2
[INFO] +- org.springframework.boot:spring-boot-starter-web:jar:1.4.3.RELEASE:compile
[INFO] | +- org.springframework.boot:spring-boot-starter:jar:1.4.3.RELEASE:compile
[INFO] | | +- org.springframework.boot:spring-boot:jar:1.4.3.RELEASE:compile
[INFO] | | +- org.springframework.boot:spring-boot-autoconfigure:jar:1.4.3.RELEASE:compile
[INFO] | | +- org.springframework.boot:spring-boot-starter-logging:jar:1.4.3.RELEASE:compile
[INFO] | | | +- ch.qos.logback:logback-classic:jar:1.1.8:compile
[INFO] | | | | +- ch.qos.logback:logback-core:jar:1.1.8:compile
[INFO] | | | | - org.slf4j:slf4j-api:jar:1.7.22:compile
[INFO] | | | +- org.slf4j:jcl-over-slf4j:jar:1.7.22:compile
[INFO] | | | +- org.slf4j:jul-to-slf4j:jar:1.7.22:compile
[INFO] | | | - org.slf4j:log4j-over-slf4j:jar:1.7.22:compile
[INFO] | | +- org.springframework:spring-core:jar:4.3.5.RELEASE:compile
[INFO] | | - org.yaml:snakeyaml:jar:1.17:runtime
[INFO] | +- org.springframework.boot:spring-boot-starter-tomcat:jar:1.4.3.RELEASE:compile
[INFO] | | +- org.apache.tomcat.embed:tomcat-embed-core:jar:8.5.6:compile
[INFO] | | +- org.apache.tomcat.embed:tomcat-embed-el:jar:8.5.6:compile
[INFO] | | - org.apache.tomcat.embed:tomcat-embed-websocket:jar:8.5.6:compile
[INFO] | +- org.hibernate:hibernate-validator:jar:5.2.4.Final:compile
[INFO] | | +- javax.validation:validation-api:jar:1.1.0.Final:compile
[INFO] | | +- org.jboss.logging:jboss-logging:jar:3.3.0.Final:compile
[INFO] | | - com.fasterxml:classmate:jar:1.3.3:compile
[INFO] | +- com.fasterxml.jackson.core:jackson-databind:jar:2.8.5:compile
[INFO] | | +- com.fasterxml.jackson.core:jackson-annotations:jar:2.8.5:compile
[INFO] | | - com.fasterxml.jackson.core:jackson-core:jar:2.8.5:compile
[INFO] | +- org.springframework:spring-web:jar:4.3.5.RELEASE:compile
[INFO] | | +- org.springframework:spring-aop:jar:4.3.5.RELEASE:compile
[INFO] | | +- org.springframework:spring-beans:jar:4.3.5.RELEASE:compile
[INFO] | | - org.springframework:spring-context:jar:4.3.5.RELEASE:compile
[INFO] | - org.springframework:spring-webmvc:jar:4.3.5.RELEASE:compile
[INFO] | - org.springframework:spring-expression:jar:4.3.5.RELEASE:compile
[INFO] +- com.hazelcast.jet:hazelcast-jet:jar:0.7.2:compile
[INFO] +- log4j:log4j:jar:1.2.12:compile
[INFO] - com.google.code.findbugs:annotations:jar:3.0.0:provided
Thank you very much.
Best,
Coco
The text was updated successfully, but these errors were encountered: