[jira] [Updated] (ATLAS-3119) Dependency Conflict: duplicate classes "org.apache.log4j.Logger" in different JARs, have different implementations
[
https://issues.apache.org/jira/browse/ATLAS-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Madhan Neethiraj updated ATLAS-3119:
Fix Version/s: (was: 0.8.4)
> 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
> Attachments: t.png, y.png
>
>
> 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
> ** 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
> ()>
> D:\testcase\TestProject\incubator-atlas-release-0.8-rc1\addons\storm-bridge-shim\target\classes
>
> D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
>
> D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
> getLogger(java.lang.String)>
> D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
> (org.apache.log4j.Logger)>
> D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
>
> D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
>
> {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 *incubator-atlas* 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)
[jira] [Updated] (ATLAS-3119) Dependency Conflict: duplicate classes "org.apache.log4j.Logger" in different JARs, have different implementations
[
https://issues.apache.org/jira/browse/ATLAS-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hello CoCooo updated ATLAS-3119:
Attachment: t.png
> 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
>
> Attachments: t.png, y.png
>
>
> 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
> ** 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
> ()>
> D:\testcase\TestProject\incubator-atlas-release-0.8-rc1\addons\storm-bridge-shim\target\classes
>
> D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
>
> D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
> getLogger(java.lang.String)>
> D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
> (org.apache.log4j.Logger)>
> D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
>
> D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
>
> {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 *incubator-atlas* 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)
[jira] [Updated] (ATLAS-3119) Dependency Conflict: duplicate classes "org.apache.log4j.Logger" in different JARs, have different implementations
[
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
** 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
()>
D:\testcase\TestProject\incubator-atlas-release-0.8-rc1\addons\storm-bridge-shim\target\classes
D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
(org.apache.log4j.Logger)>
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
{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 *incubator-atlas* 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
** 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
()>
D:\testcase\TestProject\incubator-atlas-release-0.8-rc1\addons\storm-bridge-shim\target\classes
D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
(org.apache.log4j.Logger)>
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
{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
[jira] [Updated] (ATLAS-3119) Dependency Conflict: duplicate classes "org.apache.log4j.Logger" in different JARs, have different implementations
[
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
** 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
()>
D:\testcase\TestProject\incubator-atlas-release-0.8-rc1\addons\storm-bridge-shim\target\classes
D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
(org.apache.log4j.Logger)>
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
{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
** 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
()>
D:\testcase\TestProject\incubator-atlas-release-0.8-rc1\addons\storm-bridge-shim\target\classes
D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
(org.apache.log4j.Logger)>
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
{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
[jira] [Updated] (ATLAS-3119) Dependency Conflict: duplicate classes "org.apache.log4j.Logger" in different JARs, have different implementations
[
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
** 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
()>
D:\testcase\TestProject\incubator-atlas-release-0.8-rc1\addons\storm-bridge-shim\target\classes
D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
(org.apache.log4j.Logger)>
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
{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
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
** 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_* are actually forced to be referenced via
the following invocation path:
{code:java}
// code placeholder
()>
D:\testcase\TestProject\incubator-atlas-release-0.8-rc1\addons\storm-bridge-shim\target\classes
D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
D:\cEnvironment\repository\org\slf4j\slf4j-api\1.7.21\slf4j-api-1.7.21.jar
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
(org.apache.log4j.Logger)>
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
D:\cEnvironment\repository\org\slf4j\slf4j-log4j12\1.7.21\slf4j-log4j12-1.7.21.jar
{code}
Although both of these two conflicting classes contain the referenced methods
(with the same signature), they have different implementations. This issue will
