You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apex.apache.org by "PandaMonkey (JIRA)" <ji...@apache.org> on 2018/02/22 13:24:00 UTC

[jira] [Comment Edited] (APEXCORE-805) There are dependency conflicts in apex-core/engine module

    [ https://issues.apache.org/jira/browse/APEXCORE-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372792#comment-16372792 ] 

PandaMonkey edited comment on APEXCORE-805 at 2/22/18 1:23 PM:
---------------------------------------------------------------

[~vrozov], Thanks for your reply. I analyzed the dependencies again after excluding the test and provided scope, and found that there are indeed no conflicts in the remaining dependencies. Then I looked into your pom file, and noticed an annotation

*"This is to prevent javax.servlet artifact to be pulled in*
 *as a transitive dependency during the unit tests since this*
 *conflicts with org.eclipse.jetty:jetty-servlet."*

It seems that you have changed the configuration before for this conflict. However, keeping the consistency of library version contributes to system's long-term health. To avoid the potential conflicts in evolution process, maybe upgrading javax.servlet:servlet-api from 2.5 to 3.0.1 is a good choice. After analyzing the conflicts between these two versions and

org.eclipse.jetty.orbit:javax.servlet, I confirmed that this problem can be solved in this way. Please see this attachement.[^compare.txt]


was (Author: pandamonkey):
[~vrozov], Thanks for your reply. I analyzed the dependencies again after excluding the test and provided scope, and found that there are indeed no conflicts in the remaining dependencies. Then I looked into your pom file, and noticed an annotation

*"This is to prevent javax.servlet artifact to be pulled in*
 *as a transitive dependency during the unit tests since this*
 *conflicts with org.eclipse.jetty:jetty-servlet."*

It seems that you have changed the configuration before for this conflict. However, keeping the consistency of library version contributes to system's long-term health. To avoid the potential conflicts in evolution process, maybe upgrading javax.servlet:servlet-api from 2.5 to 3.0.1 is a good choice. After analyzing the conflicts between these two versions and eclipse-servlet, I confirmed that this problem can be solved in this way. Please see this attachement.[^compare.txt]

> There are dependency conflicts in apex-core/engine module
> ---------------------------------------------------------
>
>                 Key: APEXCORE-805
>                 URL: https://issues.apache.org/jira/browse/APEXCORE-805
>             Project: Apache Apex Core
>          Issue Type: Bug
>    Affects Versions: 3.6.0
>            Reporter: PandaMonkey
>            Priority: Minor
>         Attachments: apex-core-conflicts.txt, compare.txt
>
>
> Hi, we found four pairs of JAR files in apex-core/engine contain duplicate classes.
> 1. jar-pair:<*org.eclipse.jetty.orbit:javax.servlet*:3.0.0.v201112011016:><*javax.servlet:servlet-api*:2.5:>
> 2. jar-pair:<javax.servlet:*javax.servlet-api*:3.0.1:><javax.servlet:*servlet-api*:2.5:>
> 3. jar-pair:<javax.servlet:*servlet-api:*2.5:><org.glassfish:*javax.servlet*:3.1:>
> 4. jar-pair:<*com.google.inject:guice:4.0:no_aop*><*com.google.inject:guice:3.0*:>
> Furthermore, by static analysis, we found these duplicate classes have different implementations. As the JVM only load the classes present first on the classpath and shadow the other duplicate ones with the same name. So the problem will lead to the *"NoSuchMethodException"* or *"NoSuchMethodError"*. The conflicting details are listed in the attachment. Hope this can help you. Thanks![^apex-core-conflicts.txt]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)