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
Hi, in product-iots-3.3.1 (\modules\scripts\mobile-qsg module), duplicate classes with the same fully-qualified name org.apache.http.message.BasicHeaderValueParser are included in two different libraries, i.e., org.apache.httpcomponents:httpcore:4.4.4 and org.apache.httpcomponents.wso2:httpcore:4.3.0.wso2v1.
According to "first declaration wins" class loading strategy, only this class in org.apache.httpcomponents:httpcore:4.4.4 can be loaded, and that in org.apache.httpcomponents.wso2:httpcore:4.3.0.wso2v1 will be shadowed.
By further analyzing, your project expects to invoke method <org.apache.http.message.BasicHeaderValueParser: org.apache.http.NameValuePair parseNameValuePair(org.apache.http.util.CharArrayBuffer,org.apache.http.message.ParserCursor)> in org.apache.httpcomponents.wso2:httpcore:4.3.0.wso2v1.
As it has been shadowed, so that this method defined in org.apache.httpcomponents:httpcore:4.4.4 is actually forced to be referenced via the following invocation path:
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.apache.http.message.BasicHeaderValueParser in org.apache.httpcomponents.wso2:httpcore:4.3.0.wso2v1 can be loaded (the version that product-iots expects to reference by static analysis).
This fix will not affect other libraries or class, except the above duplicate class.
Code snippet of <org.apache.http.message.BasicHeaderValueParser: org.apache.http.NameValuePair parseNameValuePair(org.apache.http.util.CharArrayBuffer,org.apache.http.message.ParserCursor)> in org.apache.httpcomponents:httpcore:4.4.4 (loaded version):
Code snippet of <org.apache.http.message.BasicHeaderValueParser: org.apache.http.NameValuePair parseNameValuePair(org.apache.http.util.CharArrayBuffer,org.apache.http.message.ParserCursor)> in org.apache.httpcomponents.wso2:httpcore:4.3.0.wso2v1
(shadowed but expected to invoke method):
and
.......
As a result, these conflicting method included in org.apache.httpcomponents.wso2:httpcore:4.3.0.wso2v1 deals with different cases, which changes the control flows and data flows. So being forced to use these methods in org.apache.httpcomponents:httpcore:4.4.4 may lead to inconsisitent semantic behaviors.
Hi, in product-iots-3.3.1 (\modules\scripts\mobile-qsg module), duplicate classes with the same fully-qualified name org.apache.http.message.BasicHeaderValueParser are included in two different libraries, i.e., org.apache.httpcomponents:httpcore:4.4.4 and org.apache.httpcomponents.wso2:httpcore:4.3.0.wso2v1.
According to "first declaration wins" class loading strategy, only this class in org.apache.httpcomponents:httpcore:4.4.4 can be loaded, and that in org.apache.httpcomponents.wso2:httpcore:4.3.0.wso2v1 will be shadowed.
By further analyzing, your project expects to invoke method <org.apache.http.message.BasicHeaderValueParser: org.apache.http.NameValuePair parseNameValuePair(org.apache.http.util.CharArrayBuffer,org.apache.http.message.ParserCursor)> in org.apache.httpcomponents.wso2:httpcore:4.3.0.wso2v1.
As it has been shadowed, so that this method defined in org.apache.httpcomponents:httpcore:4.4.4 is actually forced to be referenced via the following invocation path:
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.apache.http.message.BasicHeaderValueParser in org.apache.httpcomponents.wso2:httpcore:4.3.0.wso2v1 can be loaded (the version that product-iots 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) @ mobile-qsg ---
[INFO] org.wso2.iot:mobile-qsg:jar:3.3.1
[INFO] +- org.apache.httpcomponents:httpclient:jar:4.5.2:compile
[INFO] | +- org.apache.httpcomponents:httpcore:jar:4.4.4:compile
[INFO] | - commons-logging:commons-logging:jar:1.1.1:compile
[INFO] +- org.apache.httpcomponents.wso2:httpcore:jar:4.3.0.wso2v1:compile
[INFO] +- com.googlecode.json-simple.wso2:json-simple:jar:1.1.wso2v1:compile
[INFO] +- org.apache.httpcomponents:httpmime:jar:4.2.5:compile
[INFO] - commons-codec:commons-codec:jar:1.7:compile
Thank you very much.
Best,
Coco
The text was updated successfully, but these errors were encountered: