[
https://issues.apache.org/jira/browse/ATLAS-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hello CoCooo updated ATLAS-3119:
--------------------------------
Description:
Hi, in *incubator-atlas-release-0.8.3* (*\addons\storm-bridge-shim* module),
duplicate classes with the same fully-qualified name
_*org.apache.log4j.Logger*_ are included in two different libraries, i.e.,
*org.slf4j:log4j-over-slf4j:1.6.6* and *log4j:log4j:1.2.17*.
According to _"first declaration wins"_ class loading strategy, only this class
in *org.slf4j:log4j-over-slf4j:1.6.6* can be loaded, and that in
*log4j:log4j:1.2.17* will be shadowed.
By further analyzing, your project expects to invoke method
*<org.apache.log4j.Logger: boolean isTraceEnabled()>* in *log4j:log4j:1.2.17*.
As it has been shadowed, so that this method defined in
*org.slf4j:log4j-over-slf4j:1.6.**_6_* is actually forced to be referenced via
the following invocation path:
{code:java}
// code placeholder
<org.apache.atlas.storm.hook.StormAtlasHook: void <clinit>()>
D:\testcase\TestProject\incubator-atlas-release-0.8-rc1\addons\storm-bridge-shim\target\classes
<org.slf4j.LoggerFactory: org.slf4j.Logger getLogger(java.lang.Class)>
D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
<org.slf4j.LoggerFactory: org.slf4j.Logger getLogger(java.lang.String)>
D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
<org.slf4j.impl.Log4jLoggerFactory: org.slf4j.Logger
getLogger(java.lang.String)>
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
<org.slf4j.impl.Log4jLoggerAdapter: void <init>(org.apache.log4j.Logger)>
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
<org.slf4j.impl.Log4jLoggerAdapter: boolean isTraceCapable()>
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
<org.apache.log4j.Logger: boolean isTraceEnabled()>
{code}
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 i n pom file.
Then, according to *_"first declaration wins"_* class loading strategy, class
*org.apache.log4j.Logger* in *log4j:log4j:1.2.17* can be loaded (the version
that *log4j:log4j:1.2.17* 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.10:tree (default-cli) @ storm-bridge-shim —
[INFO] org.apache.atlas:storm-bridge-shim:jar:0.8-incubating
[INFO] +- org.apache.atlas:atlas-plugin-classloader:jar:0.8-incubating:compile
[INFO] +- org.apache.storm:storm-core:jar:1.0.0:compile
[INFO] | +- com.esotericsoftware:kryo:jar:3.0.3:compile
[INFO] | | +- com.esotericsoftware:reflectasm:jar:1.10.1:compile
[INFO] | | | - org.ow2.asm:asm:jar:5.0.3:compile
[INFO] | | +- com.esotericsoftware:minlog:jar:1.3.0:compile
[INFO] | | - org.objenesis:objenesis:jar:2.1:compile
[INFO] | +- org.clojure:clojure:jar:1.7.0:compile
[INFO] | +- com.lmax:disruptor:jar:3.3.2:compile
[INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.1:compile
[INFO] | +- org.apache.logging.log4j:log4j-core:jar:2.1:compile
[INFO] | +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.1:compile
[INFO] | +- _*org.slf4j:log4j-over-slf4j:jar:1.6.6:compile*_
[INFO] | - javax.servlet:servlet-api:jar:2.5:compile
[INFO] +- org.slf4j:slf4j-api:jar:1.7.21:compile
[INFO] +- org.slf4j:slf4j-log4j12:jar:1.7.21:compile
[INFO] | - _*log4j:log4j:jar:1.2.17:compile*_
[INFO] - org.slf4j:jul-to-slf4j:jar:1.7.21:compile
Thank you very much.
Best,
Coco
was:
Hi, in *incubator-atlas-release-0.8.3* (*\addons\storm-bridge-shim* module),
duplicate classes with the same fully-qualified name
_*org.apache.log4j.Logger*_ are included in two different libraries, i.e.,
*org.slf4j:log4j-over-slf4j:1.6.6* and *log4j:log4j:1.2.17*.
According to _"first declaration wins"_ class loading strategy, only this class
in *org.slf4j:log4j-over-slf4j:1.6.6* can be loaded, and that in
*log4j:log4j:1.2.17* will be shadowed.
By further analyzing, your project expects to invoke method
*<org.apache.log4j.Logger: boolean isTraceEnabled()>* in *log4j:log4j:1.2.17*.
As it has been shadowed, so that this method defined in
*org.slf4j:log4j-over-slf4j:1.6.**_6_* is actually forced to be referenced via
the following invocation path:
{code:java}
// code placeholder
<org.apache.atlas.storm.hook.StormAtlasHook: void <clinit>()>
D:\testcase\TestProject\incubator-atlas-release-0.8-rc1\addons\storm-bridge-shim\target\classes
<org.slf4j.LoggerFactory: org.slf4j.Logger getLogger(java.lang.Class)>
D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
<org.slf4j.LoggerFactory: org.slf4j.Logger getLogger(java.lang.String)>
D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
<org.slf4j.impl.Log4jLoggerFactory: org.slf4j.Logger
getLogger(java.lang.String)>
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
<org.slf4j.impl.Log4jLoggerAdapter: void <init>(org.apache.log4j.Logger)>
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
<org.slf4j.impl.Log4jLoggerAdapter: boolean isTraceCapable()>
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
<org.apache.log4j.Logger: boolean isTraceEnabled()>
{code}
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 i n pom file.
Then, according to *_"first declaration wins"_* class loading strategy, class
*org.apache.log4j.Logger* in *org.slf4j:log4j-over-slf4j:1.6.6* can be loaded
(the version that *log4j:log4j:1.2.17* 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.10:tree (default-cli) @ storm-bridge-shim —
[INFO] org.apache.atlas:storm-bridge-shim:jar:0.8-incubating
[INFO] +- org.apache.atlas:atlas-plugin-classloader:jar:0.8-incubating:compile
[INFO] +- org.apache.storm:storm-core:jar:1.0.0:compile
[INFO] | +- com.esotericsoftware:kryo:jar:3.0.3:compile
[INFO] | | +- com.esotericsoftware:reflectasm:jar:1.10.1:compile
[INFO] | | | - org.ow2.asm:asm:jar:5.0.3:compile
[INFO] | | +- com.esotericsoftware:minlog:jar:1.3.0:compile
[INFO] | | - org.objenesis:objenesis:jar:2.1:compile
[INFO] | +- org.clojure:clojure:jar:1.7.0:compile
[INFO] | +- com.lmax:disruptor:jar:3.3.2:compile
[INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.1:compile
[INFO] | +- org.apache.logging.log4j:log4j-core:jar:2.1:compile
[INFO] | +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.1:compile
[INFO] | +- _*org.slf4j:log4j-over-slf4j:jar:1.6.6:compile*_
[INFO] | - javax.servlet:servlet-api:jar:2.5:compile
[INFO] +- org.slf4j:slf4j-api:jar:1.7.21:compile
[INFO] +- org.slf4j:slf4j-log4j12:jar:1.7.21:compile
[INFO] | - _*log4j:log4j:jar:1.2.17:compile*_
[INFO] - org.slf4j:jul-to-slf4j:jar:1.7.21:compile
Thank you very much.
Best,
Coco
> Dependency Conflict: duplicate classes "org.apache.log4j.Logger" in different
> JARs, have different implementations
> ------------------------------------------------------------------------------------------------------------------
>
> Key: ATLAS-3119
> URL: https://issues.apache.org/jira/browse/ATLAS-3119
> Project: Atlas
> Issue Type: Bug
> Components: atlas-core
> Affects Versions: 0.8.3
> Reporter: Hello CoCooo
> Priority: Major
> Fix For: 0.8.4
>
>
> Hi, in *incubator-atlas-release-0.8.3* (*\addons\storm-bridge-shim* module),
> duplicate classes with the same fully-qualified name
> _*org.apache.log4j.Logger*_ are included in two different libraries, i.e.,
> *org.slf4j:log4j-over-slf4j:1.6.6* and *log4j:log4j:1.2.17*.
> According to _"first declaration wins"_ class loading strategy, only this
> class in *org.slf4j:log4j-over-slf4j:1.6.6* can be loaded, and that in
> *log4j:log4j:1.2.17* will be shadowed.
> By further analyzing, your project expects to invoke method
> *<org.apache.log4j.Logger: boolean isTraceEnabled()>* in
> *log4j:log4j:1.2.17*. As it has been shadowed, so that this method defined in
> *org.slf4j:log4j-over-slf4j:1.6.**_6_* is actually forced to be referenced
> via the following invocation path:
> {code:java}
> // code placeholder
> <org.apache.atlas.storm.hook.StormAtlasHook: void <clinit>()>
> D:\testcase\TestProject\incubator-atlas-release-0.8-rc1\addons\storm-bridge-shim\target\classes
> <org.slf4j.LoggerFactory: org.slf4j.Logger getLogger(java.lang.Class)>
> D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
> <org.slf4j.LoggerFactory: org.slf4j.Logger getLogger(java.lang.String)>
> D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
> <org.slf4j.impl.Log4jLoggerFactory: org.slf4j.Logger
> getLogger(java.lang.String)>
> D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
> <org.slf4j.impl.Log4jLoggerAdapter: void <init>(org.apache.log4j.Logger)>
> D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
> <org.slf4j.impl.Log4jLoggerAdapter: boolean isTraceCapable()>
> D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
> <org.apache.log4j.Logger: boolean isTraceEnabled()>
> {code}
> 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 i n pom file.
> Then, according to *_"first declaration wins"_* class loading strategy,
> class *org.apache.log4j.Logger* in *log4j:log4j:1.2.17* can be loaded (the
> version that *log4j:log4j:1.2.17* 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.10:tree (default-cli) @ storm-bridge-shim —
> [INFO] org.apache.atlas:storm-bridge-shim:jar:0.8-incubating
> [INFO] +- org.apache.atlas:atlas-plugin-classloader:jar:0.8-incubating:compile
> [INFO] +- org.apache.storm:storm-core:jar:1.0.0:compile
> [INFO] | +- com.esotericsoftware:kryo:jar:3.0.3:compile
> [INFO] | | +- com.esotericsoftware:reflectasm:jar:1.10.1:compile
> [INFO] | | | - org.ow2.asm:asm:jar:5.0.3:compile
> [INFO] | | +- com.esotericsoftware:minlog:jar:1.3.0:compile
> [INFO] | | - org.objenesis:objenesis:jar:2.1:compile
> [INFO] | +- org.clojure:clojure:jar:1.7.0:compile
> [INFO] | +- com.lmax:disruptor:jar:3.3.2:compile
> [INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.1:compile
> [INFO] | +- org.apache.logging.log4j:log4j-core:jar:2.1:compile
> [INFO] | +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.1:compile
> [INFO] | +- _*org.slf4j:log4j-over-slf4j:jar:1.6.6:compile*_
> [INFO] | - javax.servlet:servlet-api:jar:2.5:compile
> [INFO] +- org.slf4j:slf4j-api:jar:1.7.21:compile
> [INFO] +- org.slf4j:slf4j-log4j12:jar:1.7.21:compile
> [INFO] | - _*log4j:log4j:jar:1.2.17:compile*_
> [INFO] - org.slf4j:jul-to-slf4j:jar:1.7.21:compile
>
> Thank you very much.
> Best,
> Coco
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
