[JBoss JIRA] (ARQ-1944) Linkage error with arquillian-junit.jar
by Chris Rankin (JIRA)
[ https://issues.jboss.org/browse/ARQ-1944?page=com.atlassian.jira.plugin.s... ]
Chris Rankin commented on ARQ-1944:
-----------------------------------
Hmm, is your {{myorg/rest/model/OrderStatus}} class imported via a Maven {{<dependency>}} from your local repository? Because I've noticed {{maven-failsafe-plugin}} put things on the integration test classpath twice before. Whenever I've had this problem, I've needed to add something like this to the failsafe plugin's configuration:
{code:xml}<configuration>
<classpathDependencyExcludes>
<classpathDependencyExclude>groupdId:artifactId</classpathDependencyExclude>
</classpathDependencyExcludes>
</configuration>{code}
Although having said that, I've never had a linkage error because of this.
> 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)
8 years, 8 months
[JBoss JIRA] (ARQ-1944) Linkage error with arquillian-junit.jar
by Chris Rankin (JIRA)
[ https://issues.jboss.org/browse/ARQ-1944?page=com.atlassian.jira.plugin.s... ]
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)
8 years, 8 months
[JBoss JIRA] (ARQ-1944) Linkage error with arquillian-junit.jar
by Marc Richards (JIRA)
[ https://issues.jboss.org/browse/ARQ-1944?page=com.atlassian.jira.plugin.s... ]
Marc Richards edited comment on ARQ-1944 at 2/1/16 3:45 PM:
------------------------------------------------------------
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...
was (Author: talawahdotnet):
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)
8 years, 8 months
[JBoss JIRA] (ARQ-1944) Linkage error with arquillian-junit.jar
by Marc Richards (JIRA)
[ 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)
8 years, 8 months