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

[Marc Richards (JIRA)]

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

Marc Richards commented on ARQ-1944:
------------------------------------

No, the same classed isn't packaged in multiple jars and I don't have two different implementations with the same name.  I am not all that familiar with how class loaders work or how arquillian does its voodoo, but basically it looks to me like arquillian is using sun/misc/Launcher$AppClassLoader to load the test while Tomcat is using org/apache/catalina/loader/WebappClassLoader to load the backend functionality that responds to the test and myorg/rest/model/OrderStatus is referenced by both, which is not allowed.

Prior to 7.0.51 Tomcat used sun/misc/Launcher$AppClassLoader by default so there was no conflict, however now they have switched to using org/apache/catalina/loader/WebappClassLoader in order to be more inline with the Servlet Specification[1]

{quote}the web application class loader diverges from the default Java delegation model (in accordance with the recommendations in the Servlet Specification, version 2.4, section 9.7.2 Web Application Classloader). When a request to load a class from the web application's WebappX class loader is processed, this class loader will look in the local repositories first, instead of delegating before looking.{quote}

{quote}
Therefore, from the perspective of a web application, class or resource loading looks in the following repositories, in this order:

* Bootstrap classes of your JVM
* /WEB-INF/classes of your web application
* /WEB-INF/lib/*.jar of your web application
* System class loader classes (described above)
* Common class loader classes (described above)

If the web application class loader is configured with <Loader delegate="true"/> then the order becomes:

* Bootstrap classes of your JVM
* System class loader classes (described above)
* Common class loader classes (described above)
* /WEB-INF/classes of your web application
* /WEB-INF/lib/*.jar of your web application
{quote}

So I am using the <Loader delegate="true"/> workaround for now. Hopefully the arqullian team can figure out a way to make things work without the workaround.

[1] https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html#Class_Loader_Definitions

> 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)