[
https://issues.jboss.org/browse/ARQ-1944?page=com.atlassian.jira.plugin.s...
]
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_Lo...
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)