[arquillian-issues] [JBoss JIRA] (ARQ-1944) Linkage error with arquillian-junit.jar

[Chris Rankin (JIRA)]

    [ https://issues.jboss.org/browse/ARQ-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157324#comment-13157324 ] 

Chris Rankin commented on ARQ-1944:
-----------------------------------

As I understand it, the order in which Tomcat scans different locations for classes cannot possibly matter if every class exists in _exactly one_ location. The reason I raised this bug in the first place is precisely _because_ {{org.hamcrest.*}} exists in more than one place unless extraordinary steps are taken.
The fact that you are also having linkage errors when the loader order changes _strongly suggests_ that you are mistaken somewhere in your belief about how your classes are packaged.
If you look closely, you'll see that my own error also mentioned {{sun.misc.Launcher$AppClassLoader}}:
{code}java.lang.LinkageError: loader constraint violation: when resolving interface method "com.jayway.restassured.specification.ResponseSpecification.statusCode(Lorg/hamcrest/Matcher;)Lcom/jayway/restassured/specification/ResponseSpecification;" the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of the current class, org/testing/web/TroubleIT, and the class loader (instance of sun/misc/Launcher$AppClassLoader) for resolved class, com/jayway/restassured/specification/ResponseSpecification, have different Class objects for the type cification.statusCode(Lorg/hamcrest/Matcher;)Lcom/jayway/restassured/specification/ResponseSpecification; used in the signature{code}
So I think that's a {color:red}red herring{color} because my problem really(\!) was caused by duplicated classes.


> Linkage error with arquillian-junit.jar
> ---------------------------------------
>
>                 Key: ARQ-1944
>                 URL: https://issues.jboss.org/browse/ARQ-1944
>             Project: Arquillian
>          Issue Type: Bug
>    Affects Versions: 1.1.7.Final, 1.1.8.Final, 1.1.9.Final, 1.1.10.Final, 1.1.11.Final
>         Environment: JDK7, Windows 7 x64, Linux x64
>            Reporter: Chris Rankin
>         Attachments: arquillian-hamcrest-test.tar.xz
>
>
> Testing a WAR in embedded Tomcat >= 7.0.51 using Restassured, JUnit and Hamcrest matchers. (TestNG works fine).
> The test fails with this error message:
> {code}Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.404 sec <<< FAILURE! - in org.testing.web.TroubleIT
> testTrouble(org.testing.web.TroubleIT)  Time elapsed: 0.774 sec  <<< ERROR!
> java.lang.LinkageError: loader constraint violation: when resolving interface method "com.jayway.restassured.specification.ResponseSpecification.statusCode(Lorg/hamcrest/Matcher;)Lcom/jayway/restassured/specification/ResponseSpecification;" the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of the current class, org/testing/web/TroubleIT, and the class loader (instance of sun/misc/Launcher$AppClassLoader) for resolved class, com/jayway/restassured/specification/ResponseSpecification, have different Class objects for the type cification.statusCode(Lorg/hamcrest/Matcher;)Lcom/jayway/restassured/specification/ResponseSpecification; used in the signature
> 	at org.testing.web.TroubleIT.testTrouble(TroubleIT.java:35)
> {code}
> This error can be resolved in four different ways:
> - Rewrite the test using TestNG
> - Rewrite the test without using any Hamcrest matchers.
> - Remove "org.hamcrest" from {{org.jboss.arquillian.junit.container.JUnitDeploymentAppender}}.
> - Set {{@Deployment(testable = false)}} to prevent Arquillian from packaging its artifacts into the deployment in the first place.
> See [Issue #78 for arquillian-core|https://github.com/arquillian/arquillian-core/issues/78]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)